Open Stack

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 <bdobrelia at mirantis.com>
wrote:

> On 29.01.2016 10:58, Sergii Golovatiuk wrote:
> > Hi,
> >
> >
> > On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich
> > <jkirnosova at mirantis.com <mailto:jkirnosova at 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-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@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-request at 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-request at 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
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160129/82166ce1/attachment.html>