Open Stack

On 7/16/18 6:32 PM, Dan Prince 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

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-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
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando