Open Stack

On Mon, 2020-08-03 at 13:28 -0600, Alex Schultz wrote:

On Mon, Aug 3, 2020 at 6:34 AM Bogdan Dobrelya <

<mailto:bdobreli at redhat.com>

bdobreli at redhat.com

> wrote:


On 8/3/20 12:36 PM, Sagi Shnaidman wrote:

Hi, Bogdan


thanks for raising this up, although I'm not sure I understand what it

is the problem with using action plugins.

Action plugins are well known official extensions for Ansible, as any

other plugins - callback, strategy, inventory etc [1]. It is not any

hack or unsupported workaround, it's a known and official feature of

Ansible. Why can't we use it? What makes it different from filter,


I believe the cases that require the use of those should be justified.

For the given example, that manages containers in a loop via calling a

module, what the written custom callback plugin buys for us? That brings

code to maintain, extra complexity, like handling possible corner cases

in async mode, dry-run mode etc. But what is justification aside of

looks handy?


I disagree that we shouldn't use action plugins or modules.  Tasks

themselves are expensive at scale.  We saw that when we switched away

from paunch to container management in pure ansible tasks.  This

exposed that looping tasks are even more expensive and complex error

handling and workflows are better suited for modules or action plugins

than a series of tasks.  This is not something to be "fixed in

ansible".  This is the nature of the executor and strategy related

interactions.  Should everything be converted to modules and plugins?

no.  Should everything be tasks only? no.  It's a balance that must be

struck between when a specific set of complex tasks need extra data

processing or error handling.  Switching to modules or action plugins

allows us to unit test our logic. Using tasks do not have such a

concept outside of writing complex molecule testing.   IMHO it's safer

to switch to modules/action plugins than writing task logic.

I agree with Alex. Writing complex logic or trying to do error handling in tasks or jinja is not only very slow in execution, but gives us no way to properly test. Using ansible extensions like modules, action plugins, filters, etc gives us something that we can unit test, do better error handling with and therefore provides the abilty to produce a better quality result.

While it is true that it does give us more of a downstream burden, our community is well versed in reading python code and testing python code properly. Sometimes it might seem easier to an author to prototype something using ansible/jinja, but if the result is complex then an extension of some kind should be considered as a iteration and it should be unit tested. I'd go as far as to say that if we add module, we should force the requirement for unit testing through some means to ensure good code quality and maintainability.

Another benefit to using modules is that the Ansible tasks read more like a sequence of events that need to happen, which is exactly the spirit that Ansible has always advocated. When complex logic is implemented in tasks or in jinja, trying to follow the orchestration sequence becomes a *lot* harder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200804/71c278af/attachment-0001.html>