Impetus

@jagdeep-sonar has reached out to me with a failed TF run: 9653669156. Something I noticed in the output is a lot of:

...
module.agentless_gw_hadr[0].null_resource.exec_replication_cycle_on_dr (remote-exec): 1.90      2024-06-24 23:29:38,...
module.agentless_gw_hadr[0].null_resource.exec_replication_cycle_on_dr (remote-exec): 2.15      2024-06-24 23:29:39,...
module.agentless_gw_hadr[0].null_resource.exec_replication_cycle_on_dr (remote-exec): 2.40      2024-06-24 23:29:39,...
module.agentless_gw_hadr[0].null_resource.exec_replication_cycle_on_dr (remote-exec): 2.66      2024-06-24 23:29:39,...
module.agentless_gw_hadr[0].null_resource.exec_replication_cycle_on_dr (remote-exec): 2.91      2024-06-24 23:29:39,...
...

There are hundreds of lines like this and we of course want to avoid bloating the logs :) This is happening because the run-replication command is by default, meant to be run in an interactive environment (i.e. manually triggered via a user). This command is kind of a "cheap" implementation of tail or watch and tails the last line of replication.log then prints that line to stdout with a carriage return. The problem is that TF is capturing each one of the "frames" being spit out in between the carriage returns. To handle this exact solution, I added the --no-tail flag to the command, thus allowing us to run this command in a non-interactive environment. You can see https://github.com/jsonar/disaster-recovery/blob/master/docs/arbiter/arbiter.rst#running-a-replication-cycle for more information regarding this.