Launchpad reset debug level output interferes with command output

[james-nesbitt]

That DEBU getting launchpad release information for version v1.5.8 seems to be interfering with where one would expect to be entering either y or n.

After entering y and hitting enter, this is what the user sees:

❯ launchpad_1.5.9-alpha1 reset -d
DEBU checking for a launchpad upgrade
DEBU getting launchpad tag list
? Going to reset all of the hosts, which will destroy all configuration and data, Are you sure? (y/N) DEBU getting launchpad release information for version v1.5.8
? Going to reset all of the hosts, which will destroy all configuration and data, Are you sure? Yes

reported: @quadespresso
internal: PRODENG-2706

[james-nesbitt]

The issue is caused by the fact that the version check for launchpad is split into an early goroutine with a late comparison. The early goroutine message overlaps with the main thread's check for force.

The issue can be worked around by one of the following options:

1. disable the upgrade check using the command line argument
2. run launchpad with the force option (the confirmation message doesn't show up)
3. don't run launchpad in verbose/debug mode.

The issue can be resolved through one of the following:

1. change the order of "Before" Operations for the reset command to run the "force check" before the "upgrade check" so that the confirmation message appears before the upgrade check messages are created
2. disable the automatic version upgrade check (default to off)
3. disable the version check debug output

Breakdown:

• The reset command Before operation list: https://github.com/Mirantis/launchpad/blob/main/cmd/reset.go#L32
• The upgrade check fork/go-routine: https://github.com/Mirantis/launchpad/blob/main/cmd/common.go#L106
• The reset command "require force" function: https://github.com/Mirantis/launchpad/blob/main/cmd/reset.go#L60

[james-nesbitt]

Most likely I will go for the first resolution.

I won't worry about re-ordering for all of the commands, as this is the only command with such an early confirmation.

[james-nesbitt]

#556 is an attempt to deliver the 1st solution.