[openstack-dev] [tripleo] Sample Roles
aschultz at redhat.com
Thu Mar 16 16:40:43 UTC 2017
On Thu, Mar 16, 2017 at 12:13 AM, Saravanan KR <skramaja at redhat.com> wrote:
> Thanks Alex. This is really an important requirement. Today, product
> documentation has such roles incorporated to it, which is not good.
> This patch simplifies it.
> A suggestion though, instead of an external generation tool, is it not
> possible to include the individual roles yaml files directly to the a
> parent yam file? Why to add one extra step. May be we can provide all
> options in the list and say enabled as 0 or 1. Much simpler to use.
I think this goes into the long term improvement of roles. Right now
this effort is mainly to capture and centralize an existing set of
pre-canned roles. The problem with the roles as they are currently
constructed is that we need to be able to expose a way to add
requirements or dependencies. Especially as we offer pre-canned roles
to move specific services to their own nodes that used to fall under
the 'Controller' role. I see that being a deficiency in how we're
capturing the OS::TripleO::Service::* items within what we're calling
a 'role'. At the moment this is being captured in these files as
documentation to indicate if you want to use the
'ControllerOpenstack', you must also use 'Networker', 'Messaging', and
'Database' roles. I still working through the best way to organize
the roles/services in ways were these dependencies could be raised.
It might include adding some metadata into the yaml files as far as
what this role exposes so we could do some checks to ensure we've got
all our basics covered like databases/network/messaging/clustering.
That effort is outside of this specific blueprint, but something I
agree we need. There are some yaml tricks we could do to improve this
(I'm not sure heat supports them), but first I would like to just
collect all the role definitions in a single place.
> This external tool can be an mistral action to derive the final roles
> list internally.
I think this is a good long term vision, but is currently out of scope
for this effort in Pike. I would like to see improvements in how we
are exposing these services/roles to the end user. I agree that
rolling this into a workflow would be a good idea.
> Saravanan KR
> On Thu, Mar 16, 2017 at 3:37 AM, Emilien Macchi <emilien at redhat.com> wrote:
>> On Wed, Mar 15, 2017 at 5:28 PM, Alex Schultz <aschultz at redhat.com> wrote:
>>> Ahoy folks,
>>> For the Pike cycle, we have a blueprint to provide a few basic
>>> environment configurations with some custom roles. For this effort
>>> and to reduce the complexity when dealing with roles I have put
>>> together a patch to try and organize roles in a more consumable
>>> fashion. The goal behind this is that we can document the standard
>>> role configurations and also be able to ensure that when we add a new
>>> OS::TripleO::Service::* we can make sure they get applied to all of
>>> the appropriate roles. The goal of this initial change is to also
>>> allow us all to reuse the same roles and work from a single
>>> configuration repository. Please also review the existing roles in
>>> the review and make sure we're not missing any services.
>> Sounds super cool!
>>> Also my ask is that if you have any standard roles, please consider
>>> publishing them to the new roles folder so we can also identify
>>> future CI testing scenarios we would like to support.
>> Can we document it here maybe?
>>>  https://blueprints.launchpad.net/tripleo/+spec/example-custom-role-environments
>>>  https://review.openstack.org/#/c/445687/
>> Emilien Macchi
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev