Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-02-02 Thread Julia Aranovich 
I support Vitaly's proposal with 'base' group name instead of 'controller'.
So, now we have the following suggestion for role list grouping:

BASE: controller, detach-* plugin roles, murano (if it will go to plugin)
COMPUTE: compute, virt, compute-vmware, ironic
STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
OTHER: base-os, mongo, zabbix

On Mon, Feb 1, 2016 at 8:46 PM Vitaly Kramskikh 
wrote:

> Folks,
>
> 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.
>
> 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.
>
> 2016-01-29 16:53 GMT+03:00 Bogdan Dobrelya :
>
>> On 29.01.2016 13:35, Vladimir Kuklin wrote:
>> >> 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.
>>
>> I only replied to that. We did not remove role as abstraction
>>
>> --
>> 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
>>
>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
> __
> 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

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-02-01 Thread Vitaly Kramskikh 
Folks,

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.

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.

2016-01-29 16:53 GMT+03:00 Bogdan Dobrelya :

> On 29.01.2016 13:35, Vladimir Kuklin wrote:
> >> 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.
>
> I only replied to that. We did not remove role as abstraction
>
> --
> 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
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
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

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-01-29 Thread Bogdan Dobrelya 
On 29.01.2016 13:35, Vladimir Kuklin wrote:
>> 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.

I only replied to that. We did not remove role as abstraction

-- 
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

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-01-29 Thread Julia Aranovich 
Sergii,

Just to clarify: we rely on a role 'limits' attribute [1] to define is role
required for deployment ('min' limit presented in the role description) or
recommended for deployment ('recommended' limit). Roles without 'min' or
'recommended' limit are considered as optional for basic deployment.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L23-L24


On Fri, Jan 29, 2016 at 1:27 PM Vladimir Kuklin 
wrote:

> 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 > > 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 
> www.mirantis.ru
> vkuk...@mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-01-29 Thread Bogdan Dobrelya 
On 29.01.2016 10:58, Sergii Golovatiuk wrote:
> Hi,
> 
> 
> On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich
> > 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://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

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-01-29 Thread Vladimir Kuklin 
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 
wrote:

> On 29.01.2016 10:58, Sergii Golovatiuk wrote:
> > Hi,
> >
> >
> > On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich
> > > 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:

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-01-29 Thread Sergii Golovatiuk 
Hi,


On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich 
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

Re: [openstack-dev] [Fuel] [Fuel UI] Node role list grouping

2016-01-29 Thread Vladimir Kuklin 
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 
> 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 
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