<div dir="ltr">Folks<div><br></div><div>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:</div><div><br></div><div>1. Extend Nailgun roleresolver (module that actually maps tasks to nodes) to support tags (and, possibly, dynamic calculation of allocation with limited context)</div><div>2. Provide mapping of tags to particular tasks</div><div>3. Remove roles from tasks completely.</div><div><br></div><div>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')))".</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 29, 2016 at 11:39 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/28/2016 06:15 PM, Alex Schultz wrote:<br>
> Hey fuel folks,<br>
><br>
> So I know we have designation of conflicts[0] on roles to prevent two<br>
> roles from being on the same node. Should we also support a colocation<br>
> option? My thought behind this is that if we were to expose more of the<br>
> underlying functionality (such as a corosync role), we could then<br>
> require that roles like database[1] or rabbitmq[2] be combined with the<br>
> corosync role rather than relying on dirty hiera overrides. In the<br>
<br>
</span>Good point. A role definition looking like this:<br>
roles_metadata:<br>
controller:<br>
name: "Controller"<br>
description: "..."<br>
conflicts:<br>
- compute<br>
- ceph_osd<br>
colocates(/contains/requires?):<br>
- corosync<br>
- haproxy<br>
- database<br>
- messaging<br>
<br>
Would look a way better than hacky code examples you provided.<br>
<span class=""><br>
> longer term this could be useful for splitting apart some of the<br>
> controller functionality into smaller roles but still requiring that<br>
> they be next to each other on nodes.<br>
><br>
> Thoughts?<br>
><br>
> Thanks,<br>
> -Alex<br>
><br>
><br>
> [0] <a href="https://docs.fuel-infra.org/fuel-dev/develop/nailgun/customization/roles.html" rel="noreferrer" target="_blank">https://docs.fuel-infra.org/fuel-dev/develop/nailgun/customization/roles.html</a><br>
> [1] <a href="https://github.com/openstack/fuel-plugin-detach-database/blob/master/deployment_scripts/database_hiera_override.pp#L83-L92" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-plugin-detach-database/blob/master/deployment_scripts/database_hiera_override.pp#L83-L92</a><br>
> [2] <a href="https://github.com/openstack/fuel-plugin-detach-rabbitmq/blob/master/deployment_scripts/rabbitmq_hiera_override.pp#L47-L48" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-plugin-detach-rabbitmq/blob/master/deployment_scripts/rabbitmq_hiera_override.pp#L47-L48</a><br>
><br>
><br>
</span>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>