<div dir="ltr"><div>Hey folks,</div><div><br></div><div>+1 to the direction we're going with this. Like Emilien said, the skies the limit when using a flexible automation framework like Ansible. We're definitely going to need Molecule tests for the role and unit/integration tests for the podman_container module itself. I left a comment in the <a href="https://github.com/ansible/ansible/issues/46362">podman_container feature request</a> in Ansible to let the broader community know that we're working towards stabilizing that module. Hopefully that will get more contributors to help us fast track upstreaming it. It doesn't seem like Paunch is really used outside of TripleO so having it in Ansible, which has wider adoption, seems really ideal. As for backports, I think it's fair to say that Paunch for the most part "just works." When it does break it's a pain to fix. Which is even more reason to move away from it.</div><div><br></div><div>Sincerely,</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-size:12.8px">Luke Short, RHCE</span></div><div><span style="font-size:12.8px">Software Engineer, </span><span style="font-size:12.8px">OpenStack Deployment Framework</span><div style="font-size:12.8px">Red Hat, Inc.<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 11, 2019 at 11:13 AM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@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"><div dir="ltr"><div dir="ltr">On Fri, Oct 11, 2019 at 10:55 AM James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>> wrote:</div><div class="gmail_quote"><div class="gmail_attr">[snip]<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nice work! I like the approach with the new ansible role.<br>
<br>
I do think there will be a balance between what makes sense to keep in<br>
a python module vs an ansible task. If/then branching logic and<br>
conditional tasks based on previous results is of course all possible<br>
with ansible tasks, but it starts to become complex and difficult to<br>
manage. A higher level language (python) is much better at that.<br>
Personally, I prefer to view ansible as just an execution engine and<br>
would look to keep the actual application and business logic in proper<br>
reusable/testable code modules (python). Finding that right balance is<br>
likely something we can figure out in review feedback, ad-hoc<br>
discussions, etc.<br></blockquote><div><br></div><div>Ack & agreed on my side.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
An idea for a future improvement I would like to see as we move in<br>
this direction is to switch from reading the container startup configs<br>
from a single file per step<br>
(/var/lib/tripleo-config/container-startup-config-step_{{ step<br>
}}.json), to using a directory per step instead. It would look<br>
something like:<br>
<br>
/var/lib/tripleo-config/container-startup-config/step1<br>
/var/lib/tripleo-config/container-startup-config/step1/keystone-init-tasks.json<br>
/var/lib/tripleo-config/container-startup-config/step1/pacemaker-init-tasks.json<br>
etc.<br>
<br>
That way each service template can be converted to a proper ansible<br>
role in tripleo-ansible that just drops its config into the right<br>
directory on the managed node. When the tripleo-container-manage role<br>
is then executed, it will operate on those files. This would also make<br>
it much more clear what container caused a failure, since we could log<br>
the results individually instead of just getting back the union of all<br>
logs per step. I think you're patches already address this to some<br>
degree since you are looping over the contents of the single file.<br></blockquote><div><br></div><div>This is an excellent idea. One of the feedback I've got from the Upgrade folks is the need to be able to easily upgrade one service, and the current structure doesn't easily allow it. Your proposal is I think exactly addressing it; and indeed it'll help when migrating container config into their individual roles in tripleo-ansible.</div><div>I'll add that to the backlog.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The other feedback I would offer is perhaps continue to think about<br>
keeping the container implementation pluggable in some fashion. Right<br>
now you have a tasks/podman.yaml. What might it look like if we wanted<br>
to have a tasks/kubernetes.yaml in the future, and how would that be<br>
enabled?<br clear="all"></blockquote><div><br></div><div>Yes, that's what I had in mind when starting the role. The podman.yaml is for Podman logic.</div><div>We will probably have docker.yaml if we want to support Docker for FFU from Queens to Train.</div><div>And we can easily add a playbook "kubernetes.yaml" which will read the container config data, generate k8s YAML and then consume it via <a href="https://docs.ansible.com/ansible/latest/modules/k8s_module.html" target="_blank">https://docs.ansible.com/ansible/latest/modules/k8s_module.html</a> . Really there is no limit if we can make it really pluggable.</div><div><br></div><div><br></div></div>Thanks for the input and the great feedback,<br><div>-- <br><div dir="ltr"><div dir="ltr">Emilien Macchi<br></div></div></div></div>
</blockquote></div>