Open Stack

On Thu, Aug 9, 2018 at 5:33 PM Alex Schultz <aschultz at redhat.com> wrote:

> On Thu, Aug 9, 2018 at 2:56 PM, Doug Hellmann <doug at 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-request at 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-request at 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 <cclayton at redhat.com>hayutin at 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=whayutin@redhat.com&ctz=America/New_York>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180809/d756f9c1/attachment.html>