<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="text-align: left; direction: ltr; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>On Mon, 2020-08-03 at 13:28 -0600, Alex Schultz wrote:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<pre>On Mon, Aug 3, 2020 at 6:34 AM Bogdan Dobrelya <</pre>
<a href="mailto:bdobreli@redhat.com">
<pre>bdobreli@redhat.com</pre>
</a>
<pre>> wrote:</pre>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<pre><br></pre>
<pre>On 8/3/20 12:36 PM, Sagi Shnaidman wrote:</pre>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<pre>Hi, Bogdan</pre>
<pre><br></pre>
<pre>thanks for raising this up, although I'm not sure I understand what it</pre>
<pre>is the problem with using action plugins.</pre>
<pre>Action plugins are well known official extensions for Ansible, as any</pre>
<pre>other plugins - callback, strategy, inventory etc [1]. It is not any</pre>
<pre>hack or unsupported workaround, it's a known and official feature of</pre>
<pre>Ansible. Why can't we use it? What makes it different from filter,</pre>
</blockquote>
<pre><br></pre>
<pre>I believe the cases that require the use of those should be justified.</pre>
<pre>For the given example, that manages containers in a loop via calling a</pre>
<pre>module, what the written custom callback plugin buys for us? That brings</pre>
<pre>code to maintain, extra complexity, like handling possible corner cases</pre>
<pre>in async mode, dry-run mode etc. But what is justification aside of</pre>
<pre>looks handy?</pre>
</blockquote>
<pre><br></pre>
<pre>I disagree that we shouldn't use action plugins or modules. Tasks</pre>
<pre>themselves are expensive at scale. We saw that when we switched away</pre>
<pre>from paunch to container management in pure ansible tasks. This</pre>
<pre>exposed that looping tasks are even more expensive and complex error</pre>
<pre>handling and workflows are better suited for modules or action plugins</pre>
<pre>than a series of tasks. This is not something to be "fixed in</pre>
<pre>ansible". This is the nature of the executor and strategy related</pre>
<pre>interactions. Should everything be converted to modules and plugins?</pre>
<pre>no. Should everything be tasks only? no. It's a balance that must be</pre>
<pre>struck between when a specific set of complex tasks need extra data</pre>
<pre>processing or error handling. Switching to modules or action plugins</pre>
<pre>allows us to unit test our logic. Using tasks do not have such a</pre>
<pre>concept outside of writing complex molecule testing. IMHO it's safer</pre>
<pre>to switch to modules/action plugins than writing task logic.</pre>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</body>
</html>