<div dir="ltr">A couple of changes [1][2] that I proposed to kolla ansible recently as a PoC could be related here. Kolla ansible is full of almost identical roles for each service, with a lot of duplicated 'code' (YAML). The idea was to try to factor some of that out into shared roles. This results in less code and a more data-driven approach, which is inherently more configurable (for better or worse). The two changes are for configuration and user/service/endpoint registration. The same could easily be done with DB management and various other tasks. These roles are quite specific to kolla ansible, since they are tied to the configuration layout and the use of a kolla_toolbox container for executing keystone/DB ansible modules.<div><br></div><div>[1] <a href="https://review.openstack.org/587591">https://review.openstack.org/587591</a></div><div>[2] <a href="https://review.openstack.org/587590">https://review.openstack.org/587590</a></div><div><br></div><div>Mark</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 August 2018 at 10:59, Chandan kumar <span dir="ltr"><<a href="mailto:chkumar246@gmail.com" target="_blank">chkumar246@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div><div class="h5"><br>
On Fri, Aug 10, 2018 at 7:47 AM Paul Belanger <<a href="mailto:pabelanger@redhat.com">pabelanger@redhat.com</a>> wrote:<br>
><br>
> On Thu, Aug 09, 2018 at 08:00:13PM -0600, Wesley Hayutin wrote:<br>
> > On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>> wrote:<br>
> ><br>
> > > On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>
> > > wrote:<br>
> > > > Excerpts from Alex Schultz's message of 2018-08-09 14:31:34 -0600:<br>
> > > >> Ahoy folks,<br>
> > > >><br>
> > > >> I think it's time we come up with some basic rules/patterns on where<br>
> > > >> code lands when it comes to OpenStack related Ansible roles and as we<br>
> > > >> convert/export things. There was a recent proposal to create an<br>
> > > >> ansible-role-tempest[0] that would take what we use in<br>
> > > >> tripleo-quickstart-extras[1] and separate it for re-usability by<br>
> > > >> others.   So it was asked if we could work with the openstack-ansible<br>
> > > >> team and leverage the existing openstack-ansible-os_tempest[<wbr>2].  It<br>
> > > >> turns out we have a few more already existing roles laying around as<br>
> > > >> well[3][4].<br>
> > > >><br>
> > > >> What I would like to propose is that we as a community come together<br>
> > > >> to agree on specific patterns so that we can leverage the same roles<br>
> > > >> for some of the core configuration/deployment functionality while<br>
> > > >> still allowing for specific project specific customization.  What I've<br>
> > > >> noticed between all the project is that we have a few specific core<br>
> > > >> pieces of functionality that needs to be handled (or skipped as it may<br>
> > > >> be) for each service being deployed.<br>
> > > >><br>
> > > >> 1) software installation<br>
> > > >> 2) configuration management<br>
> > > >> 3) service management<br>
> > > >> 4) misc service actions<br>
> > > >><br>
> > > >> Depending on which flavor of the deployment you're using, the content<br>
> > > >> of each of these may be different.  Just about the only thing that is<br>
> > > >> shared between them all would be the configuration management part.<br>
> > > ><br>
> > > > Does that make the 4 things separate roles, then? Isn't the role<br>
> > > > usually the unit of sharing between playbooks?<br>
> > > ><br>
> > ><br>
> > > It can be, but it doesn't have to be.  The problem comes in with the<br>
> > > granularity at which you are defining the concept of the overall<br>
> > > action.  If you want a role to encompass all that is "nova", you could<br>
> > > have a single nova role that you invoke 5 different times to do the<br>
> > > different actions during the overall deployment. Or you could create a<br>
> > > role for nova-install, nova-config, nova-service, nova-cells, etc etc.<br>
> > > I think splitting them out into their own role is a bit too much in<br>
> > > terms of management.   In my particular openstack-ansible is already<br>
> > > creating a role to manage "nova".  So is there a way that I can<br>
> > > leverage part of their process within mine without having to duplicate<br>
> > > it.  You can pull in the task files themselves from a different so<br>
> > > technically I think you could define a ansible-role-tripleo-nova that<br>
> > > does some include_tasks: ../../os_nova/tasks/install.<wbr>yaml but then<br>
> > > we'd have to duplicate the variables in our playbook rather than<br>
> > > invoking a role with some parameters.<br>
> > ><br>
> > > IMHO this structure is an issue with the general sharing concepts of<br>
> > > roles/tasks within ansible.  It's not really well defined and there's<br>
> > > not really a concept of inheritance so I can't really extend your<br>
> > > tasks with mine in more of a programming sense. I have to duplicate it<br>
> > > or do something like include a specific task file from another role.<br>
> > > Since I can't really extend a role in the traditional OO programing<br>
> > > sense, I would like to figure out how I can leverage only part of it.<br>
> > > This can be done by establishing ansible variables to trigger specific<br>
> > > actions or just actually including the raw tasks themselves.   Either<br>
> > > of these concepts needs some sort of contract to be established to the<br>
> > > other won't get broken.   We had this in puppet via parameters which<br>
> > > are checked, there isn't really a similar concept in ansible so it<br>
> > > seems that we need to agree on some community established rules.<br>
> > ><br>
> > > For tripleo, I would like to just invoke the os_nova role and pass in<br>
> > > like install: false, service: false, config_dir:<br>
> > > /my/special/location/, config_data: {...} and it spit out the configs.<br>
> > > Then my roles would actually leverage these via containers/etc.  Of<br>
> > > course most of this goes away if we had a unified (not file based)<br>
> > > configuration method across all services (openstack and non-openstack)<br>
> > > but we don't. :D<br>
> > ><br>
> ><br>
> > I like your idea here Alex.<br>
> > So having a role for each of these steps is too much management I agree,<br>
> > however<br>
> > establishing a pattern of using tasks for each step may be a really good<br>
> > way to cleanly handle this.<br>
> ><br>
> > Are you saying something like the following?<br>
> ><br>
> > openstack-nova-role/<br>
> > * * /tasks/<br>
> > * * /tasks/install.yml<br>
> > * * /tasks/service.yml<br>
> > * */tasks/config.yml<br>
> > * */taks/main.yml<br>
> > ---------------------------<br>
> > # main.yml<br>
> ><br>
> > include: install.yml<br>
> > when: nova_install|bool<br>
> ><br>
> > include: service.yml<br>
> > when: nova_service|bool<br>
> ><br>
> > include: config.yml<br>
> > when: nova_config.yml<br>
> > ------------------------------<wbr>--------------------<br>
> ><br>
> > Interested in anything other than tags :)<br>
> > Thanks<br>
> ><br>
> This is basically what I do with roles i write, allow the user to decide to step<br>
> over specific tasks. For example, I have created nodepool_task_manager variable<br>
> with the following:<br>
><br>
>     <a href="http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/defaults/main.yaml#n16" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/ansible-role-<wbr>nodepool/tree/defaults/main.<wbr>yaml#n16</a><br>
>     <a href="http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/tasks/main.yaml" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/ansible-role-<wbr>nodepool/tree/tasks/main.yaml</a><br>
><br>
> Been using it for a few years now, works much better then tags for me.  The<br>
> phases are pre, install, configure, service right now.<br>
<br>
<br>
</div></div>Thanks Alex for starting the conversation.<br>
There are few other ansible roles for tempest and it's friends (stackviz)<br>
<a href="https://github.com/redhat-openstack/infrared/tree/master/plugins/tempest" rel="noreferrer" target="_blank">https://github.com/redhat-<wbr>openstack/infrared/tree/<wbr>master/plugins/tempest</a><br>
<a href="https://github.com/openstack/tempest/tree/master/roles" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>tempest/tree/master/roles</a><br>
<br>
It would be a great idea to improve ansible-role-os_tempest role and<br>
modify it such a way that it can be re-used by anyone.<br>
I will start working on this.<br>
<br>
Thanks,<br>
<br>
Chandan Kumar<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>