[openstack-dev] [tripleo] introducing python-tripleo-helper

Emilien Macchi emilien at redhat.com
Mon Mar 6 19:28:31 UTC 2017


On Fri, Feb 24, 2017 at 3:02 PM, Gonéri Le Bouder <goneri at lebouder.net> wrote:
> Hi all,
>
> TL/DR:
>
> - use Python to do drive TripleO deployment
> - RPM based
> - used to be a bit specific, closer to upstream now (RDO)
> - unit-test
> - maybe a good candidate to join the TripleO umbrella
>
> Following a discussion with Emilien, I would like to introduce
> python-tripleo-helper.
>
> python-tripleo-helper is a Python library that wrapper all the
> operations required to get a working TripleO. The initial goal was to
> have a solution to automate and validate the deployment of TripleO in
> our lab environment.
>
> Since the full deployment flow is based on a modern programming
> language, it's also possible to write more complex operations.
>
> For instance, this is a test that I did some month ago:
> Once the Overcloud was running, we started a "chaos monkey" thread that
> was randomly disconnecting controllers. We were running tempest in the
> main thread to collect results. Python makes all these interactions
> easy.
>
> At this point, we support libvirt and the OpenStack as the target
> environment. We use a couple of hacks to be able to use a regular
> OpenStack cloud (OSP7). bare-metal is not supported yet even if it's
> definitely a low-hanging fruit.
>
> python-tripleo-helper relies on RPM packages but we are open to
> contribution to support the other packaging solutions.
>
> Till some weeks ago python-tripleo-helper was not really generical. This
> is the reason why it's still maintained in the redhat-openstack
> namespace. Nicolas Hicher pushed a couple of patches to be able to use
> it with RDO and CentOS, I guess we can now consider a move to the
> TripleO umbrella.

Have you investigated what could (and / or couldn't if applies) reside
in tripleoclient / tripleo-common instead of having a new tool?

If we found out that we need this new tool in TripleO, let's move it
upstream. Otherwise, I'm in favor of consolidating tools and re-use
our existing workflow & client tools.

Thanks,

> --
>     Gonéri Le Bouder
>
> __________________________________________________________________________
> 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
>



-- 
Emilien Macchi



More information about the OpenStack-dev mailing list