Open Stack

IMHO, roles (inside collections) do provide quite good abstraction layer as they allow us to change implementation without changing the API (the variables passed to the role).

If the role uses an embedded module, external one or lots of tasks to achieve the same functionality it is an implementation details.

At any point in time we can refactor the role internals and create new modules, swap them, .... without messing its consumption.

I cannot say the same about playbooks, especially those that call modules directly. If they call roles, we should be fine.

> On 2 Nov 2020, at 11:55, Jesse Pretorius <jesse at odyssey4.me> wrote:
> 
> On Thu, 2020-10-29 at 07:00 -0600, Alex Schultz wrote:
>> On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya <
>>  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
>