On 7/16/18 6:32 PM, Dan Prince wrote:
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
I think that should be just ansible commands triggered natively via
tripleoclient. Why would we validate with heat deploying a throwaway
one-time ephemeral stacks (for undercloud/standalon) each time a user
runs that heat installer? We had to introduce the virtual stack state
tracking system [0], for puppet manifests compatibility sakes only (it
sometimes rely on states CREATE vs UPDATE), which added more "ephemeral
complexity" in DF. I'm not following why would we validate ephemeral
stacks or using it as an additional moving part?
[0]
https://review.openstack.org/#/q/topic:bug/1778505+(status:open+OR+status:merged)
'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
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
__________________________________________________________________________
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
