Open Stack

On Thu, 2020-10-29 at 07:00 -0600, Alex Schultz wrote:

On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya <

<mailto:bdobreli at redhat.com>

bdobreli at 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).


<snip>


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.

It seems to me that we need to consider:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201102/1945f8b5/attachment.html>