On Tue, Aug 4, 2020 at 5:42 AM Bogdan Dobrelya <bdobreli@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