[tripleo][ansible] the current action plugins use patterns are suboptimal?

Emilien Macchi emilien at redhat.com
Mon Aug 10 20:48:09 UTC 2020

On Tue, Aug 4, 2020 at 5:42 AM Bogdan Dobrelya <bdobreli at redhat.com> wrote:

> I can understand that ansible should not be fixed for some composition
> tasks what require iterations and have complex logic for its "unit of
> work". And such ones also should be unit tested indeed. What I do not
> fully understand though is then what abandoning paunch for its action
> plugin had bought for us in the end?
> Paunch was self-contained and had no external dependencies on
> fast-changing ansible frameworks. There was also no need for paunch to
> handle the ansible-specific execution strategies and nuances, like "what
> if that action plugin is called in async or in the check-mode?" Unit
> tests exited in paunch as well. It was easy to backport changes within a
> single code base.
> So, looking back retrospectively, was rewriting paunch as an action
> plugin a simplification of the deployment framework? Please reply to
> yourself honestly. It does pretty same things but differently and added
> external framework. It is now also self-contained action plugin, since
> traditional tasks cannot be used in loops for this goal because of
> performance reasons.

I asked myself the same questions several times and to me the major driver
around removing paunch was to move the container logic into Ansible modules
which would be community supported vs paunch-runner code.
The Ansible role version has also brought more plugability with other
components of the framework (Ansible strategies, debugging, etc) but I
don't think it was the major reason why we wrote it.

The simplification aspect was mostly about removing the CLI which I don't
think was needed at the end; and also the unique name thing which was a
mistake and caused us many troubles as you know.

To summarize, action plugins may be a good solution indeed, but perhaps
> we should go back and use paunch instead of ansible? Same applies for
> *some* other tasks? That would also provide a balance, for action
> plugins, tasks and common sense.

Sagi is currently working on replacing the podman_containers action plugin
by a module that will be able to process multiple containers at the same
time, so we'll have less tasks and potentially faster operations at scale.
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200810/5fc6a93a/attachment.html>

More information about the openstack-discuss mailing list