Open Stack

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

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