On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz <aschu...@redhat.com> wrote:
> On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann <d...@doughellmann.com> > wrote: > > Excerpts from Alex Schultz's message of 2018-08-09 14:31:34 -0600: > >> Ahoy folks, > >> > >> I think it's time we come up with some basic rules/patterns on where > >> code lands when it comes to OpenStack related Ansible roles and as we > >> convert/export things. There was a recent proposal to create an > >> ansible-role-tempest[0] that would take what we use in > >> tripleo-quickstart-extras[1] and separate it for re-usability by > >> others. So it was asked if we could work with the openstack-ansible > >> team and leverage the existing openstack-ansible-os_tempest[2]. It > >> turns out we have a few more already existing roles laying around as > >> well[3][4]. > >> > >> What I would like to propose is that we as a community come together > >> to agree on specific patterns so that we can leverage the same roles > >> for some of the core configuration/deployment functionality while > >> still allowing for specific project specific customization. What I've > >> noticed between all the project is that we have a few specific core > >> pieces of functionality that needs to be handled (or skipped as it may > >> be) for each service being deployed. > >> > >> 1) software installation > >> 2) configuration management > >> 3) service management > >> 4) misc service actions > >> > >> Depending on which flavor of the deployment you're using, the content > >> of each of these may be different. Just about the only thing that is > >> shared between them all would be the configuration management part. > > > > Does that make the 4 things separate roles, then? Isn't the role > > usually the unit of sharing between playbooks? > > > > It can be, but it doesn't have to be. The problem comes in with the > granularity at which you are defining the concept of the overall > action. If you want a role to encompass all that is "nova", you could > have a single nova role that you invoke 5 different times to do the > different actions during the overall deployment. Or you could create a > role for nova-install, nova-config, nova-service, nova-cells, etc etc. > I think splitting them out into their own role is a bit too much in > terms of management. In my particular openstack-ansible is already > creating a role to manage "nova". So is there a way that I can > leverage part of their process within mine without having to duplicate > it. You can pull in the task files themselves from a different so > technically I think you could define a ansible-role-tripleo-nova that > does some include_tasks: ../../os_nova/tasks/install.yaml but then > we'd have to duplicate the variables in our playbook rather than > invoking a role with some parameters. > > IMHO this structure is an issue with the general sharing concepts of > roles/tasks within ansible. It's not really well defined and there's > not really a concept of inheritance so I can't really extend your > tasks with mine in more of a programming sense. I have to duplicate it > or do something like include a specific task file from another role. > Since I can't really extend a role in the traditional OO programing > sense, I would like to figure out how I can leverage only part of it. > This can be done by establishing ansible variables to trigger specific > actions or just actually including the raw tasks themselves. Either > of these concepts needs some sort of contract to be established to the > other won't get broken. We had this in puppet via parameters which > are checked, there isn't really a similar concept in ansible so it > seems that we need to agree on some community established rules. > > For tripleo, I would like to just invoke the os_nova role and pass in > like install: false, service: false, config_dir: > /my/special/location/, config_data: {...} and it spit out the configs. > Then my roles would actually leverage these via containers/etc. Of > course most of this goes away if we had a unified (not file based) > configuration method across all services (openstack and non-openstack) > but we don't. :D > I like your idea here Alex. So having a role for each of these steps is too much management I agree, however establishing a pattern of using tasks for each step may be a really good way to cleanly handle this. Are you saying something like the following? openstack-nova-role/ * * /tasks/ * * /tasks/install.yml * * /tasks/service.yml * */tasks/config.yml * */taks/main.yml --------------------------- # main.yml include: install.yml when: nova_install|bool include: service.yml when: nova_service|bool include: config.yml when: nova_config.yml -------------------------------------------------- Interested in anything other than tags :) Thanks > > Thanks, > -Alex > > > Doug > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Wes Hayutin Associate MANAGER Red Hat <https://www.redhat.com/> w <cclay...@redhat.com>hayu...@redhat.com T: +1919 <+19197544114>4232509 IRC: weshay <https://red.ht/sig> View my calendar and check my availability for meetings HERE <https://calendar.google.com/calendar/b/1/embed?src=whayu...@redhat.com&ctz=America/New_York>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev