Open Stack

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.

[1] https://review.openstack.org/587591
[2] https://review.openstack.org/587590

Mark

On 10 August 2018 at 10:59, Chandan kumar <chkumar246 at gmail.com> wrote:

> Hello,
>
> On Fri, Aug 10, 2018 at 7:47 AM Paul Belanger <pabelanger at 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 <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
> > >
> > 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180810/7f91bccc/attachment.html>