Open Stack

On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya <bdobreli at redhat.com> wrote:
>
> Hi,
>
> 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).
>
> Ansible brings declarative DSL that sometimes can better and simpler and
> faster describes things to do and shape inputs data, than if the same
> would be done in python, in the client.
>
> What should be the trivial thing and non-trivial then?
>
> Well, I think that example [0] illustrates such a trivial thing. A new
> playbook [1] would only install a few packages then "returns" back into
> python and calls a new ansible module [2]. And that new module only
> wraps [3] the same code being removed from the client:
>
> from tripleo_common.image import build
> ...
> manager = build.ImageBuildManager(<args>)
>
> 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..."

> [0] https://review.opendev.org/#/c/759954/
>
> [1]
> https://review.opendev.org/#/c/759953/3/tripleo_ansible/playbooks/cli-overcloud-image-build.yaml
>
> [2]
> https://review.opendev.org/#/c/759953/3/tripleo_ansible/ansible_plugins/modules/tripleo_overcloud_image_build.py@26
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>