<div dir="ltr"><div>This thread deserves an update:</div><div><br></div><div>- tripleo-ansible has now a paunch module, calling openstack/paunch as a library.</div><div><a href="https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/ansible_plugins/modules/paunch.py">https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/ansible_plugins/modules/paunch.py</a></div><div><br></div><div>And is called here for paunch apply:<br></div><div><a href="https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/common/deploy-steps-tasks.yaml#L232-L254">https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/common/deploy-steps-tasks.yaml#L232-L254</a></div><div><br></div><div>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.</div><div><br></div><div>- 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: <a href="https://review.opendev.org/#/c/686196">https://review.opendev.org/#/c/686196</a>. It's being tested here: <a href="https://review.opendev.org/#/c/687651/">https://review.opendev.org/#/c/687651/</a> 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).<br></div><div><br></div><div>The second approach is a serious prototype I would like to continue further but before I would like some feedback.</div><div>As for the feedback received in the previous answers, people would like to keep a "print-cmd" like, which makes total sense.</div><div>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.</div><div>We could also extract the container management tasks to its own playbook so an operator who would usually run:</div><div>$ paunch debug (...) --action print-cmd</div><div><br></div><div>replaced by:<br></div><div>$ ansible-playbook --check -i inventory.yaml containers.yaml</div><div><br></div><div>A few benefits of this new role:</div><div>- leverage ansible modules (we plan to upstream podman_container module)</div><div>- could be easier to maintain and contribute (python vs ansible)</div><div>- could potentially be faster. I want to investigate usage of async actions/polls in the role.</div><div><br></div><div>Challenges:</div><div>- no unit tests like in paunch, will need good testing with Molecule</div><div>- 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.<br></div><div><br></div><div>More feedback is very welcome and anyone interested to contribute please let me know.<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 5:03 AM Bogdan Dobrelya <<a href="mailto:bdobreli@redhat.com">bdobreli@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16.09.2019 18:07, Emilien Macchi wrote:<br>
> On Mon, Sep 16, 2019 at 11:47 AM Rabi Mishra <<a href="mailto:ramishra@redhat.com" target="_blank">ramishra@redhat.com</a> <br>
> <mailto:<a href="mailto:ramishra@redhat.com" target="_blank">ramishra@redhat.com</a>>> wrote:<br>
> <br>
> I'm not sure if podman as container tool would move in that<br>
> direction, as it's meant to be a command line tool. If we really<br>
> want to reduce the overhead of so many layers in TripleO and podman<br>
> is the container tool for us (I'll ignore the k8s related<br>
> discussions for the time being), I would think the logic of<br>
> translating the JSON configs to podman calls should be be in ansible<br>
> (we can even write a TripleO specific podman module).<br>
> <br>
> <br>
> I think we're both in strong agreement and say "let's convert paunch <br>
> into ansible module".<br>
<br>
I support the idea of calling paunch code as is from an ansible module. <br>
Although I'm strongly opposed against re-implementing the paunch code <br>
itself as ansible modules. That only brings maintenance burden (harder <br>
will be much to backport fixes into Queens and Train) and more place for <br>
potential regressions, without any functional improvements.<br>
<br>
> And make the module robust enough for our needs. Then we could replace <br>
> paunch by calling the podman module directly.<br>
> -- <br>
> Emilien Macchi<br>
<br>
<br>
-- <br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>