Hi,
On Fri, Aug 10, 2018 at 5:00 AM, Wesley Hayutin <whayu...@redhat.com> 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
>
I like the idea. We may also add upgrade tasks here also
>
> 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
>
>
--
Best Regards,
Sergii Golovatiuk
__________________________________________________________________________
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
