[tripleo] Deprecating paunch CLI?

Emilien Macchi emilien at redhat.com
Wed Oct 9 22:58:58 UTC 2019


This thread deserves an update:

- tripleo-ansible has now a paunch module, calling openstack/paunch as a
library.
https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/ansible_plugins/modules/paunch.py

And is called here for paunch apply:
https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/common/deploy-steps-tasks.yaml#L232-L254

In theory, we could deprecate "paunch apply" now as we don't need it
anymore. I was working on porting "paunch cleanup" but it's still WIP.

- I've been working on a new Ansible role which could totally replace
Paunch, called "tripleo-container-manage", which has been enough for me to
deploy an Undercloud: https://review.opendev.org/#/c/686196. It's being
tested here: https://review.opendev.org/#/c/687651/ and as you can see the
undercloud was successfully deployed without Paunch. Note that some
container parameters haven't been ported and upgrade untested (this is a
prototype).

The second approach is a serious prototype I would like to continue further
but before I would like some feedback.
As for the feedback received in the previous answers, people would like to
keep a "print-cmd" like, which makes total sense.
I was thinking we could write a proper check mode for the podman_container
module, which could output the podman commands that are run by the module.
We could also extract the container management tasks to its own playbook so
an operator who would usually run:
$ paunch debug (...) --action print-cmd

replaced by:
$ ansible-playbook --check -i inventory.yaml containers.yaml

A few benefits of this new role:
- leverage ansible modules (we plan to upstream podman_container module)
- could be easier to maintain and contribute (python vs ansible)
- could potentially be faster. I want to investigate usage of async
actions/polls in the role.

Challenges:
- no unit tests like in paunch, will need good testing with Molecule
- we need to invest a lot in testing it, Paunch has a lot of edge cases
that we carried over the cycles to manage containers.

More feedback is very welcome and anyone interested to contribute please
let me know.

On Tue, Sep 17, 2019 at 5:03 AM Bogdan Dobrelya <bdobreli at redhat.com> wrote:

> On 16.09.2019 18:07, Emilien Macchi wrote:
> > On Mon, Sep 16, 2019 at 11:47 AM Rabi Mishra <ramishra at redhat.com
> > <mailto:ramishra at redhat.com>> wrote:
> >
> >     I'm not sure if podman as container tool would move in that
> >     direction, as it's meant to be a command line tool. If we really
> >     want to reduce the overhead of so many layers in TripleO and podman
> >     is the container tool for us (I'll ignore the k8s related
> >     discussions for the time being), I would think the  logic of
> >     translating the JSON configs to podman calls should be be in ansible
> >     (we can even write a TripleO specific podman module).
> >
> >
> > I think we're both in strong agreement and say "let's convert paunch
> > into ansible module".
>
> I support the idea of calling paunch code as is from an ansible module.
> Although I'm strongly opposed against re-implementing the paunch code
> itself as ansible modules. That only brings maintenance burden (harder
> will be much to backport fixes into Queens and Train) and more place for
> potential regressions, without any functional improvements.
>
> > And make the module robust enough for our needs. Then we could replace
> > paunch by calling the podman module directly.
> > --
> > Emilien Macchi
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
>

-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191009/0d2e62a5/attachment-0001.html>


More information about the openstack-discuss mailing list