On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya <
bdobreli@redhat.com
> wrote:
In today TripleO client development we invoke ansible playbooks instead
of Mistral workflows. I believe this may only be justified for
non-trivial things. Otherwise please just import python modules into the
client command actions without introducing additional moving parts in
the form of ansible modules (that import the same python modules as well).
I see no point of adding a new playbook and a new module for that
trivial example. Those 4 packages could (and should) be as well
installed from the client caller code without any ansible involved in
the middle IMO.
While I can agree to a certain extent, there's actually some good
reasons to even move trivial bits into ansible. Personally I'm not
certain the switch to using ansible under the covers from some cli
actions is an improvement (questionable logging, error handling isn't
great), there is a case for certain actions. As we discussed at the
PTG, the overcloud image building process is one of those things that
actually has to be executed on bare metal. If we wanted to continue to
look at containerizing the cli, we need to be able to invoke this
action from within the container but build on an external host. This
is something that is trivial with the switch to an ansible playbook
that isn't available when running under the pure python as it exists
today. Container builds would be another example action that is
required to run on a bare metal host. Additionally the movement of
this invocation to an ansible module also allows the action to be
moved into something like the undercloud installation as an optional
action as part of the deployment itself. It's not exactly without
merit in this case.
I don't really care one way or another for this action, however I
don't think it's as simple as saying "oh it's just a few lines of code
so we shouldn't..."
What it sounds like is that there's a need for documented guidelines. A lot of changes have been made as part of a learning process and we now know a lot more about what tasks are better suited to be done directly in the client vs via ansible roles vs
via ansible modules. If we can document these best practises then we can guide any new changes according to them.
1. Requirements - what needs to get done
2. Constraints - does the action need something special like access to devices or kernel API's
3. Testability - something in python or an ansible module is unit testable, whereas an ansible role is more difficult to properly test
4. Scalability - complex ansible tasks/vars scale far worse that ansible modules
5. Maintainability - many factors are involved here, but sometimes efficiency should be sacrificed for simplicity