Open Stack

On 06/30/2016 10:21 AM, Vladimir Kuklin wrote:
> 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.

A brilliant idea, Vladimir! I fully support that. Would you create a spec?
And fancy "Tags" are much better then boring "Roles" :-)

> 
> On Wed, Jun 29, 2016 at 11:39 AM, Bogdan Dobrelya
> <bdobrelia at mirantis.com <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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 <http://www.mirantis.ru/>
> vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
> 
> 
> __________________________________________________________________________
> 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