Open Stack

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 <cjeanner at redhat.com>
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 <dprince at redhat.com
> > <mailto:dprince at redhat.com>> wrote:
> >
> >     On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret
> >     <cjeanner at redhat.com <mailto: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
> >     <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://OpenStack-dev-request@lists.openstack.org?subject:
> unsubscribe>
> >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     <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://OpenStack-dev-request@lists.openstack.org?subject:
> unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >
> >
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180717/9ab1946f/attachment.html>