<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> 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[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.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></blockquote><div><br></div><div>I like your idea here Alex.</div><div>So having a role for each of these steps is too much management I agree, however</div><div>establishing a pattern of using tasks for each step may be a really good way to cleanly handle this.</div><div><br></div><div>Are you saying something like the following?</div><div><br></div><div>openstack-nova-role/</div><div>* * /tasks/</div><div>* * /tasks/install.yml</div><div>* * /tasks/service.yml</div><div>* */tasks/config.yml</div><div>* */taks/main.yml</div><div>---------------------------</div><div># main.yml </div><div><br></div><div>include: install.yml</div><div>when: nova_install|bool</div><div><br></div><div>include: service.yml</div><div>when: nova_service|bool</div><div><br></div><div>include: config.yml</div><div>when: nova_config.yml</div><div>--------------------------------------------------</div><div><br></div><div>Interested in anything other than tags :)<br></div><div>Thanks</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
-Alex<br>
<br>
> Doug<br>
><br>
> __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="font-family:sans-serif"><p style="font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;text-transform:uppercase"><span style="font-size:14px">Wes Hayutin</span></p><p style="font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;text-transform:uppercase"><span style="color:rgb(0,0,0);font-size:10px">Associate MANAGER</span><br></p><p style="color:rgb(153,153,153);font-family:overpass,sans-serif;margin:0px;font-size:10px"><a href="https://www.redhat.com/" target="_blank" style="color:rgb(0,136,206);margin:0px">Red Hat <br><br></a></p><span style="color:rgb(153,153,153);font-family:overpass,sans-serif;font-size:10px;margin:0px"><p style="margin:0px"><span style="color:rgb(153,153,153);margin:0px;padding:0px"><a href="mailto:cclayton@redhat.com" target="_blank" style="color:rgb(0,136,206);margin:0px">w</a><a href="mailto:hayutin@redhat.com">hayutin@redhat.com</a>   </span><span style="color:rgb(153,153,153)"> T: </span><a href="tel:+19197544114" target="_blank" style="color:rgb(0,136,206);margin:0px">+1919</a>4232509<span style="color:rgb(153,153,153)">     IRC:  </span>weshay<br></p></span><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img width="90" height="auto" src="https://www.redhat.com/files/brand/email/sig-redhat.png"></a></td></tr></tbody></table></div><br style="font-family:sans-serif"><span style="font-family:sans-serif">View</span><span style="font-family:sans-serif"> </span><span style="font-family:sans-serif">my</span><span style="font-family:sans-serif"> </span><span style="font-family:sans-serif">calendar</span><span style="font-family:sans-serif"> and check </span><span style="font-family:sans-serif">my</span><span style="font-family:sans-serif"> availability for meetings </span><span id="inbox-inbox-docs-internal-guid-37a711e5-1f4c-b3c1-221b-f589048200c7"><a href="https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">HERE</span></a></span><br></div></div>