Open Stack

Hi TripleO Folks,

I'm raising this topic to the ML because it appears we have some divergence
regarding some design around the way the Validations should be used with
and without TripleO and I wanted to have a larger audience, in particular
PTL and core thoughts around this topic.

The current situation is:
We have an openstack tripleo validator set of sub commands to handle
Validation (run, list ...).
The CLI validation is taking several parameters as an entry point and in
particular the stack/plan, Openstack authentication and static inventory
file.

By asking the stack/plan name, the CLI is trying to verify and understand
if the plan or the stack is valid, if the Overcloud exists somewhere in the
cloud before passing that to the tripleo-ansible-inventory script and
trying to generate a static inventory file in regard to what --plan or
stack has been passed.
The code is mainly here: [1].

This behavior implies several constraints:
* Validation CLI needs Openstack authentication in order to do those checks
* It introduces some complexity in the Validation code part: querying Heat
to get the plan name to be sure the name provided is correct, get the
status of the stack... In case of Standalone deployment, it adds more
complexity then.
* This code is only valid for "standard" deployments and usage meaning it
doesn't work for Standalone, for some Upgrade and FFU stages and needs to
be bypassed for pre-undercloud deployment.
* We hit several blockers around this part of code.

My proposal is the following:

Since we are thinking of the future of Validation and we want something
more robust, stronger, simpler, usable and efficient, I propose to get rid
of the plan/stack and authentication functionalities in the Validation
code, and only ask for a valid inventory provided by the user.
I propose as well to create a new entry point in the TripleO CLI to
generate a static inventory such as:
openstack tripleo inventory generate --output-file my-inv.yaml
and then:
openstack tripleo validator run --validation my-validation --inventory
my-inv.yaml

By doing that, I think we gain a lot in simplification, it's more robust,
and Validation will only do what it aims for: wrapp Ansible execution to
provide better logging information and history.

The main concerns about this approach is that the user will have to provide
a valid inventory to the Validation CLI.
I understand the point of view of getting something fully autonomous, and
the way of just kicking *one* command and the Validation can be *magically*
executed against your cloud, but I think the less complex the Validation
code is, the more robust, stable and usable it will be.

Deferring a specific entry point for the inventory, which is a key part of
post deployment action, seems something more clear and robust as well.
This part of code could be shared and used for any other usages instead of
calling the inventory script stored into tripleo-validations. It could then
use the tripleo-common inventory library directly with tripleoclient,
instead of calling from client -> tripleo-validations/scripts -> query
tripleo-common inventory library.

I know it changes a little bit the usage (adding one command line in the
execution process for getting a valid inventory) but it's going in a less
buggy and racy direction.
And the inventory should be generated only once, or at least at any big
major cloud change.

So, I'm glad to get your thoughts on that topic and your overall views
around this topic.

Thanks,
Mathieu

[1]
https://github.com/openstack/tripleo-validations/blob/master/tripleo_validations/tripleo_validator.py#L338-L382
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210303/31717016/attachment-0001.html>