Hello,
On Fri, Aug 10, 2018 at 7:47 AM Paul Belanger <pabelan...@redhat.com> wrote:
>
> On Thu, Aug 09, 2018 at 08:00:13PM -0600, Wesley Hayutin wrote:
> > 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
> >
> This is basically what I do with roles i write, allow the user to decide to
> step
> over specific tasks. For example, I have created nodepool_task_manager
> variable
> with the following:
>
>
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/defaults/main.yaml#n16
>
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/tasks/main.yaml
>
> Been using it for a few years now, works much better then tags for me. The
> phases are pre, install, configure, service right now.
Thanks Alex for starting the conversation.
There are few other ansible roles for tempest and it's friends (stackviz)
https://github.com/redhat-openstack/infrared/tree/master/plugins/tempest
https://github.com/openstack/tempest/tree/master/roles
It would be a great idea to improve ansible-role-os_tempest role and
modify it such a way that it can be re-used by anyone.
I will start working on this.
Thanks,
Chandan Kumar
__________________________________________________________________________
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
