Bug 1601739 - [RFE] Support listing and launching validators from the client, same as from the GUI
Summary: [RFE] Support listing and launching validators from the client, same as from ...
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-tripleoclient
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact: Gurenko Alex
URL: https://blueprints.launchpad.net/trip...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-17 07:13 UTC by Udi
Modified: 2019-08-12 05:28 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Udi 2018-07-17 07:13:20 UTC
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.

Comment 2 Cédric Jeanneret 2018-07-17 08:45:48 UTC
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.

Cheers,

C.




¹ https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/undercloud_preflight.py
² https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/undercloud_config.py#L555
³ https://review.openstack.org/582917https://review.rdoproject.org/r/#/c/14847/https://github.com/openstack/tripleo-common/blob/master/workbooks/validations.yaml#L8

Comment 3 Cédric Jeanneret 2018-07-18 12:00:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.