On Wed, Oct 9, 2019 at 7:05 PM Emilien Macchi <emilien@redhat.com> wrote:
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_ansi...
And is called here for paunch apply: https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/commo...
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.
Nice work! I like the approach with the new ansible role. I do think there will be a balance between what makes sense to keep in a python module vs an ansible task. If/then branching logic and conditional tasks based on previous results is of course all possible with ansible tasks, but it starts to become complex and difficult to manage. A higher level language (python) is much better at that. Personally, I prefer to view ansible as just an execution engine and would look to keep the actual application and business logic in proper reusable/testable code modules (python). Finding that right balance is likely something we can figure out in review feedback, ad-hoc discussions, etc. An idea for a future improvement I would like to see as we move in this direction is to switch from reading the container startup configs from a single file per step (/var/lib/tripleo-config/container-startup-config-step_{{ step }}.json), to using a directory per step instead. It would look something like: /var/lib/tripleo-config/container-startup-config/step1 /var/lib/tripleo-config/container-startup-config/step1/keystone-init-tasks.json /var/lib/tripleo-config/container-startup-config/step1/pacemaker-init-tasks.json etc. That way each service template can be converted to a proper ansible role in tripleo-ansible that just drops its config into the right directory on the managed node. When the tripleo-container-manage role is then executed, it will operate on those files. This would also make it much more clear what container caused a failure, since we could log the results individually instead of just getting back the union of all logs per step. I think you're patches already address this to some degree since you are looping over the contents of the single file. The other feedback I would offer is perhaps continue to think about keeping the container implementation pluggable in some fashion. Right now you have a tasks/podman.yaml. What might it look like if we wanted to have a tasks/kubernetes.yaml in the future, and how would that be enabled? Thanks -- -- James Slagle --