[RFE] Prompt when encountering expansion scenarios

[sadsfae]

We have a policy of setting existing, running OCP/OSP clouds as --no-wipe prior to quads doing expansion shuffling, this is because with active DHCP/bootp traffic it's impossible to kickstart newly added systems.

This RFE is to provide an additional scheduling check when quads-cli comes across an expansion scenario to prompt if it is an OSP/OCP workload.

Expansion into existing environment detected, is this an OSP/OCP assignment? (Y/N)

If you choose Y then it sets quads-cli --mod-cloud cloud0X --no-wipe for you. If you choose N it proceeds like a normal expansion with only the newly added nodes being kickstarted and validated.

If the assignment is already set as --no-wipe you do not get a prompt at all when using quads-cli to add additional future systems to expand the environment.

[grafuls]

We can easily narrow the expansion scenario when running add-schedule on a cloud which has current/active schedules.

[sadsfae]

Additionally, in OSP/OCP expansion scenarios (if you choose Y) we most likely want those systems powered off when they move to avoid disruption in the target environment from existing cruft and processes on the systems being moved in.

We do however want non OSP/OCP expansions if not purposely set to --no-wipe to continue with kickstart and validation of net-new systems moving in.

Proposal: If an expansion cloud is set to --no-wipe then ensure systems are powered off during the minimal move set of move-and-rebuild-hosts.py.

[kambiz-aghaiepour]

As opposed to prompting the user when a schedule is being added to hosts where the target cloudXX was already released why not just auto-convert a cloudXX environment upon initial release? It seems to be the prompting on expansions can be cumbersome. Also the expansion use case is likely an OCP or OSP environment, so why not auto-convert a cloud to no-wipe upon the initial successful release? And if you want to convert it back to --wipe, you can do it with mod-cloud.

[sadsfae]

As opposed to prompting the user when a schedule is being added to hosts where the target cloudXX was already released why not just auto-convert a cloudXX environment upon initial release? It seems to be the prompting on expansions can be cumbersome. Also the expansion use case is likely an OCP or OSP environment, so why not auto-convert a cloud to no-wipe upon the initial successful release? And if you want to convert it back to --wipe, you can do it with mod-cloud.

Expansions can be OSP/OCP-based but not always, also most assignments don't become expansions only a small minority.

It's excessive to bring another new cloud-level argparse that has mechanics that toggle the --wipe and --no-wipe values when assignments do not turn into expansions, that's additional logic and conditional processing of automation and extra code and one more thing to remember.

The time when you have the least amount of information about a workload is before it's active (--define-cloud phase) and we've seen many times that the original stated description in the ticket or even subsequent usage after it's released can change, sometimes a few times.

You effectively are having to remember a setting to use in --define-cloud at a time you know the least about the future direction, usage and expansion needs of an assignment that you likely won't even need.

By the time an assignment is ever in an expansion scenario the usage is well-defined (hence the need for expansion), not before it's assigned.

Having to carry forward a new argparse at the cloud level is one more thing you'd have to remember to do, to satiate a potential future expansion scenario which statistically is the small minority of assignments. This assumes that the pre-release workload description and usage won't change, which isn't the case some of the time.

Having instead a prescriptive, localized conditional check that only prompts you if something is being expand and --no-wipe isn't set requires carrying forward zero new things to remember but gives a second chance to review the --no-wipe setting.

Most of the time we do not forget this so you'd never see except in cases where it was not applied mistakenly for OSP/OCP.

All the other expansion scenarios absolutely do not want to be set --no-wipe because we want the net-new sytems to be kickstarted, cleaned and validated before they mix up with systems running existing workloads.

What we want out of this RFE is a simple, conditional operator check that only arises when all conditions are met:

1. Expansion scenario
2. --no-wipe is not set on the active, destination cloud

Almost all the time we do not forget to set --no-wipe in OSP/OCP expansions, this will catch those times when we do so most of the time you'll never see it because we're fairly good about it.

[kambiz-aghaiepour]

having an --auto-no-wipe is a simple fix to help to automate the process, so that you won't have to answer a prompt or pass a -y argument to add-schedule. Of course the prompt (or -y) can still be there as a secondary safeguard in the off chance you forgot to use --auto-no-wipe for an OSP/OCP allocation. It's a win/win.

[sadsfae]

having an --auto-no-wipe is a simple fix to help to automate the process, so that you won't have to answer a prompt or pass a -y argument to add-schedule. Of course the prompt (or -y) can still be there as a secondary safeguard in the off chance you forgot to use --auto-no-wipe for an OSP/OCP allocation. It's a win/win.

This is not needed and one extra thing to remember, that you have to define at time when you know the least about how an assignment is going to be used (or if it will even be expanded).

This does not fit into the scope of what we're trying to address here, which requires zero things to remember and gives an additional check if and only if you forget to apply --no-wipe at the expansion phase, which most assignments never turn into anyway.

[sadsfae]

As both changes have merit, we'll track/implement the more core argparse --auto-no-wipe command enhancement in a separate RFE #360 so our change-sets are a little smaller.