Open Stack

On Wed, Oct 9, 2019 at 7:05 PM Emilien Macchi <emilien at 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_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.

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
--