Open Stack

On Mon, Aug 3, 2020 at 6:34 AM Bogdan Dobrelya <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.

IMHO the issue that I see with the switch to Action plugins is the
increased load on the ansible "controller" node during execution.
Modules may be better depending on the task being managed. But I
believe with unit testing, action plugins or modules provide a cleaner
and more testable solution than writing roles consisting only of
tasks.



>
> > lookup, inventory or any other plugin we already use?
> > Action plugins are also used wide in Ansible itself, for example
> > templates plugin is implemented with action plugin [2]. If Ansible can
> > use it, why can't we? I don't think there is something with "fixing"
> > Ansible, it's not a bug, this is a useful extension.
> > What regards the mentioned action plugin for podman containers, it
> > allows to spawn containers remotely while skipping the connection part
> > for every cycle. I'm not sure you can "fix" Ansible not to do that, it's
> > not a bug. We may not see the difference in a few hosts in CI, but it
> > might be very efficient when we deploy on 100+ hosts oro even 1000+
> > hosts. In order to evaluate this on bigger setups to understand its
> > value we configured both options - to use action plugin or usual module.
> > If better performance of action plugin will be proven, we can switch to
> > use it, if it doesn't make a difference on bigger setups - then I think
> > we can easily switch back to using an usual module.
> >
> > Thanks
> >
> > [1] https://docs.ansible.com/ansible/latest/plugins/plugins.html
> > [2]
> > https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/template.py
> >
> > On Mon, Aug 3, 2020 at 11:19 AM Bogdan Dobrelya <bdobreli at redhat.com
> > <mailto:bdobreli at redhat.com>> wrote:
> >
> >     There is a trend of writing action plugins, see [0], for simple things,
> >     like just calling a module in a loop. I'm not sure that is the
> >     direction
> >     TripleO should go. If ansible is inefficient in this sort of tasks
> >     without custom python code written, we should fix ansible. Otherwise,
> >     what is the ultimate goal of that trend? Is that having only action
> >     plugins in roles and playbooks?
> >
> >     Please kindly asking the community to stop that, make a step back and
> >     reiterate with the taken approach. Thank you.
> >
> >     [0] https://review.opendev.org/716108
> >
> >
> >     --
> >     Best regards,
> >     Bogdan Dobrelya,
> >     Irc #bogdando
> >
> >
> >
> >
> > --
> > Best regards
> > Sagi Shnaidman
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>