On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret <cjean...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev