<div dir="ltr">Sergii<div><br></div><div>I disagree with you here a little bit. Role abstraction is a useful thing from high-level standpoint. I would suggest that this list of roles grouping, e.g. which roles are mandatory and which are configured within which group can be specified:</div><div><br></div><div>1) in global settings of Nailgun</div><div>2) per-plugin</div><div>3) per environment in UI</div><div><br></div><div>This should cover all the cases even for very flexible roles allocation.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 12:58 PM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div class="gmail_extra">
<br><div class="gmail_quote"><span class="">On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich <span dir="ltr"><<a href="mailto:jkirnosova@mirantis.com" target="_blank">jkirnosova@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi folks,<div><br>Our team has started a redesign of node roles panel [1] on Add Nodes/Edit Roles screens in Fuel UI.<br></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px">Currently, node roles panel takes a big part of the screen and User have to scroll down to node list to check nodes and then scroll up again to check roles. This becomes more actual for desktops with a small screen.</span><br></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px">And we faced with the question of grouping new role containers in the panel. There is out initial suggestion [2]:</span><br></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px"><br></span></div><div><span style="font-size:14px;font-family:Arial,sans-serif;color:rgb(51,51,51)"><img src="cid:1528c783f32da6402da2" alt="role-list-grouping-1.png" style="max-width:100%"><br></span></div><div><ul><li>the first group (the first line on the screenshot) is roles which are required or recommended for deployment (controller, compute, cinder, etc.).<br></li></ul></div></div></blockquote></span><div>It's not true. There can be deployments without Controllers or without computes or without Storage. </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul><li>the second group is optional roles which are not mandatory for deployment (base-os, virt, etc.)<br></li><li>the last group is roles which are unavailable at the moment because of some restrictions. For example, mongo role can not be assigned to a node if ceilometer setting is not enabled on Settings tab</li></ul><div>BUT there is also a suggestion [3] (see comment #6) to add a new role 'category' attribute into its yaml description [4] that will reflect the role function.<br></div><div>For example, cinder, ceph-osd, cinder-vmware roles are from Storage category; compute, ironic are Compute and so on.</div></div><div>This new 'category' attribute will also allow proper calculating of an environment capacity: it does not make sense to count CPU and RAM of non-compute nodes or HDD of non-storage nodes.</div><div><br></div><div>So, we have an initial proposal for such a grouping by a role category:</div><div><br></div>CONTROLLER: controller<div>COMPUTE: compute, virt, compute-vmware, ironic</div><div>STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd</div><div>OTHER: base-os, mongo</div><div><br></div><div>And we ask your help to review this grouping, i.e. to define the list of possible role categories and to distribute the roles between these categories.</div></div></blockquote><div><br></div></span><div>We removed role as abstraction from library. It's very very artificial abstraction. Instead we use tasks, grouping them to different combinations. That allows plugin developers to adjust reference architecture to their needs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><div><br></div><div>Best regards,<br></div><div><div><div>Julia</div></div><div><br></div><div>P.S. We also should take into account, that Fuel plugins can also provide their own roles.</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel" target="_blank">https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel</a></div><div>[2] <a href="http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png" target="_blank">http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png</a></div><div>[3] <a href="https://bugs.launchpad.net/fuel/+bug/1375750" target="_blank">https://bugs.launchpad.net/fuel/+bug/1375750</a></div><div>[4] <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142</a></div><div><br></div></div></div>
<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></blockquote></div><br></div></div>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="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>