Open Stack

Folks

This is a good idea actually. I think we could implement it by extending
our node metadata model to support hierarchical tags such as
"provides::database" or "service::messaging::rabbitmq" which would then
actually map onto a set of tasks. In this case 'roles' would be simply
collections of tags. When a user wants to change things, he just can
reassign specific tags from the controller, e.g. database or messaging, to
another node. Then we would show something like 'node-1: controller MINUS
database and messaging, node-2: database and messaging'.  This would mean
the following changes:

1. Extend Nailgun roleresolver (module that actually maps tasks to nodes)
to support tags (and, possibly, dynamic calculation of allocation with
limited context)
2. Provide mapping of tags to particular tasks
3. Remove roles from tasks completely.

We could then also improve our dynamic calculation of things that changed
with YAQL expressions to actually look into nodes tags instead of writing
hacky 4-liners parsing metadata, e.g. run 'rabbitmq' task when
"changed($.nodes.where(tag.matches('service::messaging::rabbitmq')))".

>From what I know from Nailgun standpoint, this should be easy to implement,
I think something like 2 weeks. Obviously, it requires some time to design
and get consensus within core reviewers.

On Wed, Jun 29, 2016 at 11:39 AM, Bogdan Dobrelya <bdobrelia at mirantis.com>
wrote:

> On 06/28/2016 06:15 PM, Alex Schultz wrote:
> > Hey fuel folks,
> >
> > So I know we have designation of conflicts[0] on roles to prevent two
> > roles from being on the same node. Should we also support a colocation
> > option?  My thought behind this is that if we were to expose more of the
> > underlying functionality (such as a corosync role), we could then
> > require that roles like database[1] or rabbitmq[2] be combined with the
> > corosync role rather than relying on dirty hiera overrides.  In the
>
> Good point. A role definition looking like this:
> roles_metadata:
>   controller:
>     name: "Controller"
>     description: "..."
>     conflicts:
>       - compute
>       - ceph_osd
>     colocates(/contains/requires?):
>       - corosync
>       - haproxy
>       - database
>       - messaging
>
> Would look a way better than hacky code examples you provided.
>
> > longer term this could be useful for splitting apart some of the
> > controller functionality into smaller roles but still requiring that
> > they be next to each other on nodes.
> >
> > Thoughts?
> >
> > Thanks,
> > -Alex
> >
> >
> > [0]
> https://docs.fuel-infra.org/fuel-dev/develop/nailgun/customization/roles.html
> > [1]
> https://github.com/openstack/fuel-plugin-detach-database/blob/master/deployment_scripts/database_hiera_override.pp#L83-L92
> > [2]
> https://github.com/openstack/fuel-plugin-detach-rabbitmq/blob/master/deployment_scripts/rabbitmq_hiera_override.pp#L47-L48
> >
> >
> >
> __________________________________________________________________________
> > 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
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> 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
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160630/0c0c2e0a/attachment.html>