[tripleo] please avoid creating ansible playbooks that call modules for trivial tasks

Rabi Mishra ramishra at redhat.com
Thu Oct 29 13:38:17 UTC 2020


On Thu, Oct 29, 2020 at 6:57 PM Bogdan Dobrelya <bdobreli at redhat.com> wrote:

> On 10/29/20 1:45 PM, Rabi Mishra wrote:
> > On Thu, Oct 29, 2020 at 4:59 PM Bogdan Dobrelya <bdobreli at redhat.com
> > <mailto: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?
> >
> >
> > Yes, we did create a number of playbooks/ansible modules for some
> > trivial things starting with https://review.opendev.org/#/c/716286/ (I
> > had a comment about it in that patch and it seems you reviewed the patch
> > too), that could have been achieved by making a simple tripleo-common
> > api calls.
>
> Yes, that change belongs to a massive conversion effort that contains
> hundreds of patches in the topic. Also the created ansible module
> doesn't look trivial to me, since the result [0] of that work looked
> much simpler than the original parts [1], [2], [3] of workflow and its
> code. And "trivial" playbook for the given example only wraps the
> ansible module for the caller. So that approach taken for that example
> looks justified.
>

Though we're not debating that patch here but what we do in the future, not
sure why it's not trivial for you. That ansible module[0] wraps single
tripleo-common api call  "stack_param_utils.update_parameters", which could
have been easily called from tripleoclient[2], like the example you had
given.

>
> [0]
>
> https://review.opendev.org/#/c/712604/7/tripleo_ansible/ansible_plugins/modules/tripleo_plan_parameters_update.py
>
> [1]
>
> https://review.opendev.org/#/c/298682/23/tripleo_common/actions/parameters.py
>
> [2]
>
> https://review.opendev.org/#/c/716286/4/tripleoclient/v1/overcloud_deploy.py
>
> [3] https://review.opendev.org/#/c/540398/2/workbooks/plan_management.yaml
>
> >
> > IMO, creating playbooks for every cli action and moving all logic from
> > tripleoclient to ansible modules/playboos would have helped us in either
> > getting rid of tripleoclient or make it very thin. We did discuss that
> > in the victoria PTG[1]. Agreed that we would  end up with some
> > inefficient stuff (like what you've mentioned) during the transition and
> > later, but the user experience with ansible playbooks compared to
> > current logging in cli actions would have outweighed that.
> >
> > However, over the last cycle I've seen some resistance to  go in that
> > direction (i.e moving everything from tripleoclient to
> > playbooks/role/ansible mddules), If we want to keep some stuff in
> > tripleolcient (and some in ansible modules/playbooks), then I would
> > agree we should not make it complex by writing playbooks/modules for
> > things that could be achieved by simple tripleo-common api calls.
> >
> > [1] https://etherpad.opendev.org/p/tripleo-future-of-tripleoclient
> >
> >     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.
> >
> >     [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
> >
> >
> >
> >
> > --
> > Regards,
> > Rabi Mishra
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
>

-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201029/f9248575/attachment.html>


More information about the openstack-discuss mailing list