Bogdan I do no think that this is confusing as we should have actually a place where we tie roles to particular tasks. How do you expect our orchestrator to generate a graph without knowing which tasks to execute on which node?
On Fri, Jan 29, 2016 at 2:59 PM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > On 29.01.2016 10:58, Sergii Golovatiuk wrote: > > Hi, > > > > > > On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich > > <jkirnos...@mirantis.com <mailto: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]: > > > > 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. > > That seems *very* confusing as all role labels are still sitting at > their places in task definitions. See for 'primary-controller', > 'controller', 'compute' etc. We can say we "dropped" only once we: > - get rid of them in *all* places > - update task schema docs [0] lagging far behind, which is the most > critical thing to remove confusion, see related topic [1] > > [0] > > https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-January/085208.html > > > > > > > > > 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://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 > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __________________________________________________________________________ > 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
