Description of problem:
Today, validators are run from the CLI by calling ansible-playbook to run them directly. There should be a sub-command tree for validator-related operations in the client, for example:
openstack validators list
openstack validators run <<validator name>>
openstack validators status <<optional validator name>>
The command should also support an optional --stack parameter in cases where the plan name is not the default "overcloud". The list and status commands should also support an optional --group parameter to filter the output for a group of validators. The run command should also support running a group or running all validators.
We have to have several cases:
- undercloud pre-deploy validations
- overcloud pre-deploy validations
- day2 validations
In the first case we will need to get a proper way to run the checks without the support of Mistral nor any undercloud service. A current example of such runs can be found in the undercloud_preflight¹ and related call happening before the deploy².
I'm currently working in integrating some ansible-playbook capabilities, aiming first the undercloud preflight checks³. This will add the possibility to actually use the openstack-tripleo-validations content.
Just before that, I also added openstack-tripleo-validations as a package dependency to the python-tripleoclient⁴ so that we get that package earlier than previously (it was installed during the undercloud deploy).
In the second case, we can actually use some Mistral workflow, especially this one: tripleo.validations.v1.run_validation⁵
We should ensure we can actually point to the relevant validations, meaning "those that affect only the overcloud" (including some on the undercloud, like the disk space ensuring we can get the containers, and so on).
The third case is a bit like the second case - we want to ensure we actually have a consistent and valid env before updating/upgrading the undercloud, same for the overcloud.
The command should thus be a bit more complicated, and probably should involve the "group" we want to validate (undercloud, overcloud), and either detect the step we're in (pre-deploy, pre-up(date|grade)) automatically, or accept it as an option. This should also affect the shown validations (overcloud validations aren't the same as the undercloud, for example).
Hope those hints will help getting a nice and proper way to actually validate the stacks in all their extend.
Actually the BP I link to this issue concerns mainly Stein - and I'm not sure we'll be able to backport it to Queens nor Rocky. We'll see how it comes.