<div dir="ltr">I support Vitaly's proposal with 'base' group name instead of 'controller'.<div><span style="line-height:1.5">So, now we have the following suggestion for role list grouping:</span><br></div><div><br></div><div><div>BASE: controller, detach-* plugin roles, murano (if it will go to plugin)</div><div>COMPUTE: compute, virt, compute-vmware, ironic</div><div>STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd</div><div>OTHER: base-os, mongo, zabbix</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 1, 2016 at 8:46 PM Vitaly Kramskikh <<a href="mailto:vkramskikh@mirantis.com">vkramskikh@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Folks,<br><br></div>That's true, Nailgun is still using Role entity - in DB, API, plugins can provide new roles, etc., and it's not going away, at least in 9.0.<br><br>I'm fine with proposed set of role groups, except the "controller" group. We don't have anything else but "controller" role in this group in the base installation, but there are plugins that can detach some services from the controller, like detach-database, detach-rabbitmq, etc. So these roles with detached services should also be in the "controller" group, but it looks a little illogical to me. So I'd prefer to go with something like "base" or "core" group.<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-29 16:53 GMT+03:00 Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 29.01.2016 13:35, Vladimir Kuklin wrote:<br>
>> We removed role as abstraction from library. It's very very artificial<br>
>> abstraction. Instead we use tasks, grouping them to different<br>
>> combinations. That allows plugin developers to adjust reference<br>
>> architecture to their needs.<br>
<br>
</span>I only replied to that. We did not remove role as abstraction<br>
<div><div><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>
</div></div></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div><div dir="ltr"><div><div dir="ltr">Vitaly Kramskikh,<br>Fuel UI Tech Lead,<br>Mirantis, Inc.</div></div></div></div>
</div>
__________________________________________________________________________<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>
</blockquote></div>