Open Stack

We should also add support for the openstack client to launch the other
validators that are used in the GUI. There are validators for the overcloud
as well, and new validators are added all the time.

These validators are installed under
/usr/share/openstack-tripleo-validations/validations/ and they're launched
by the command:
ansible-playbook -i /usr/bin/tripleo-ansible-inventory
/usr/share/openstack-tripleo-validations/validations/<<validator-name.py>>

Cedric, feel free to open an RFE.




Regards,
Udi Kalifon; Senior QE; RHOS-UI Automation


On Mon, Jul 16, 2018 at 6:32 PM, Dan Prince <dprince at redhat.com> wrote:

> On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret <cjeanner at redhat.com>
> wrote:
> >
> > Dear Stackers,
> >
> > In order to let operators properly validate their undercloud node, I
> > propose to create a new subcommand in the "openstack undercloud" "tree":
> > `openstack undercloud validate'
> >
> > This should only run the different validations we have in the
> > undercloud_preflight.py¹
> > That way, an operator will be able to ensure all is valid before
> > starting "for real" any other command like "install" or "upgrade".
> >
> > Of course, this "validate" step is embedded in the "install" and
> > "upgrade" already, but having the capability to just validate without
> > any further action is something that can be interesting, for example:
> >
> > - ensure the current undercloud hardware/vm is sufficient for an update
> > - ensure the allocated VM for the undercloud is sufficient for a deploy
> > - and so on
> >
> > There are probably other possibilities, if we extend the "validation"
> > scope outside the "undercloud" (like, tripleo, allinone, even overcloud).
> >
> > What do you think? Any pros/cons/thoughts?
>
> I think this command could be very useful. I'm assuming the underlying
> implementation would call a 'heat stack-validate' using an ephemeral
> heat-all instance. If so way we implement it for the undercloud vs the
> 'standalone' use case would likely be a bit different. We can probably
> subclass the implementations to share common code across the efforts
> though.
>
> For the undercloud you are likely to have a few extra 'local only'
> validations. Perhaps extra checks for things on the client side.
>
> For the all-in-one I had envisioned using the output from the 'heat
> stack-validate' to create a sample config file for a custom set of
> services. Similar to how tools like Packstack generate a config file
> for example.
>
> Dan
>
> >
> > Cheers,
> >
> > C.
> >
> >
> >
> > ¹
> > http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/
> tripleoclient/v1/undercloud_preflight.py
> > --
> > Cédric Jeanneret
> > Software Engineer
> > DFG:DF
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180717/403af722/attachment.html>