Sergii 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:
1) in global settings of Nailgun 2) per-plugin 3) per environment in UI This should cover all the cases even for very flexible roles allocation. On Fri, Jan 29, 2016 at 12:58 PM, Sergii Golovatiuk < sgolovat...@mirantis.com> wrote: > Hi, > > > On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich <jkirnos...@mirantis.com> > wrote: > >> Hi folks, >> >> Our team has started a redesign of node roles panel [1] on Add Nodes/Edit >> Roles screens in Fuel UI. >> 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. >> >> And we faced with the question of grouping new role containers in the >> panel. There is out initial suggestion [2]: >> >> [image: role-list-grouping-1.png] >> >> - the first group (the first line on the screenshot) is roles which >> are required or recommended for deployment (controller, compute, cinder, >> etc.). >> >> It's not true. There can be deployments without Controllers or without > computes or without Storage. > >> >> - the second group is optional roles which are not mandatory for >> deployment (base-os, virt, etc.) >> - 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 >> >> 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. >> For example, cinder, ceph-osd, cinder-vmware roles are from Storage >> category; compute, ironic are Compute and so on. >> 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. >> >> So, we have an initial proposal for such a grouping by a role category: >> >> CONTROLLER: controller >> COMPUTE: compute, virt, compute-vmware, ironic >> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd >> OTHER: base-os, mongo >> >> 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. >> > > 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. > > >> >> Best regards, >> Julia >> >> P.S. We also should take into account, that Fuel plugins can also provide >> their own roles. >> >> [1] >> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel >> [2] >> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png >> [3] https://bugs.launchpad.net/fuel/+bug/1375750 >> [4] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142 >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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 vkuk...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev