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@redhat.com> wrote:
On 16.09.2019 18:07, Emilien Macchi wrote:
> On Mon, Sep 16, 2019 at 11:47 AM Rabi Mishra <ramishra@redhat.com
> <mailto:ramishra@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