Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Bogdan Dobrelya]

On 7/16/18 6:32 PM, Dan Prince wrote:

On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret  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

Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Cédric Jeanneret]

Dear Stackers,

Seeing the answers on and off-list, we're moving forward!

So, here are the first steps:

A blueprint has been created:
https://blueprints.launchpad.net/tripleo/+spec/validation-framework

I've started a draft of the spec, based on the feedbacks and discussions
I could have:
https://review.openstack.org/#/c/583475/

Please, feel free to comment the spec and add your thoughts - this is a
really great opportunity to get a proper validation framework in
tripleoclient directly.

Thank you for your feedback and attention.

Cheers,

C.


On 07/16/2018 05:27 PM, Cédric Jeanneret 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?
> 
> Cheers,
> 
> C.
> 
> 
> 
> ¹
> http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/tripleoclient/v1/undercloud_preflight.py
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Udi Kalifon]

I opened this RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1601739


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


On Tue, Jul 17, 2018 at 8:42 AM, Cédric Jeanneret 
wrote:

>
>
> On 07/17/2018 06:57 AM, Udi Kalifon wrote:
> > 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>>
>
> Hey, funky - I'm currently adding the support for ansible-playbook (in
> an "easy, fast and pre-step" way) to the tripleoclient in order to be
> able to run validations from that very same location:
> https://review.openstack.org/582917
>
> Guess we're on the same track :).
>
> >
> > Cedric, feel free to open an RFE.
>
> Will do once we have the full scope :).
>
> >
> >
> >
> >
> > Regards,
> > Udi Kalifon; Senior QE; RHOS-UIAutomation
> >
> >
> > On Mon, Jul 16, 2018 at 6:32 PM, Dan Prince  > > wrote:
> >
> > On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret
> > mailto: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
> >  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
> >  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
> >  unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >
> >
>
> --
> Cédric Jeanneret
> Software Engineer
> DFG:DF
>
>
> __
> OpenStack 

Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Cédric Jeanneret]

On 07/17/2018 06:57 AM, Udi Kalifon wrote:
> 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/<>

Hey, funky - I'm currently adding the support for ansible-playbook (in
an "easy, fast and pre-step" way) to the tripleoclient in order to be
able to run validations from that very same location:
https://review.openstack.org/582917

Guess we're on the same track :).

> 
> Cedric, feel free to open an RFE.

Will do once we have the full scope :).

> 
> 
> 
> 
> Regards,
> Udi Kalifon; Senior QE; RHOS-UIAutomation
> 
> 
> On Mon, Jul 16, 2018 at 6:32 PM, Dan Prince  > wrote:
> 
> On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret
> mailto: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
> 
> 
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Pablo Iranzo Gómez]

Hi


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?


Great idea.

We did something similar from support side with https://citellus.org not just
for upgrades but also for identifying ongoing issues also from sosreports.

Wes did a POC at https://review.openstack.org/#/c/553571/ for integrating it 
too.

So if we could even reuse them somehow, that will be great.

Thanks!
Pablo


Cheers,

C.


--

Pablo Iranzo Gómez (pablo.ira...@redhat.com)  GnuPG: 0x5BD8E1E4
Senior Software Maintenance Engineer - OpenStack
RHC{A,SS,DS,VA,E,SA,SP,AOSP}, JBCAA  #110-215-852


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Udi Kalifon]

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

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

> On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret 
> 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
>
__
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

Re: [openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Dan Prince]

On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret  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

[openstack-dev] [tripleo] New "validation" subcommand for "openstack undercloud"

[Cédric Jeanneret]

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?

Cheers,

C.



¹
http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/tripleoclient/v1/undercloud_preflight.py
-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
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