Open Stack

Andriy,

May be 'role' was not the correct word  here.
For me role are compute, controller, base-os, cinder, mongo. I know that we
can specify that a task A should be executed on some role (controller and
compute for example) and a task B on some other roles (Cinder for example).

To come back to my previous examples with the label feature presented by
Irina :
1/ not apply nova-nfs plugin in all compute nodes
we would assign a label on the nodes on which we want to setup the nfs
backend storage for ephemeral volume. Then in the deploymodule we would be
able to put a condition to setup it or not. Here the cleaner solution would
be in th task.yaml to define a condition to execute the task for a given
role AND a given label (here role would be equal to compute and label could
be equal to nfs)

2/ a plugin to define availability zone:
if I have 3 compute nodes, I would be able to assign az1 label to compute
node 1  and 2 and label az2 to compute node 3. Then in the plugin
deployment moduel I would be able to setup a az called az1 with compute
nodes 1 and 2 and a az called az2 with compute node 3. It is not custom
role as these nodes are compute.


regards

Samuel

2015-06-24 20:20 GMT+02:00 Andriy Popovych <apopovych at mirantis.com>:

> Samuel,
>
> AFAIK labels will not be related to tasks, it's just marks for filtering
> nodes.
> What "roles" means for you?
>
> we have tasks (A, B, C, D) and on some nodes tasks A B D should be
> executed, on some B C etc. So plugin can provide specials marks or tags or
> sets (we call it "roles") and link
> tasks with it. In example before we can describe roles 'a' and 'b' to
> group 2 different sets of tasks ABD and BC. So A links with 'a', B with 'a'
> and 'b', C with 'b' and D  with 'a'). Both roles 'a' and 'b' can be
> implemented in context of ONE plugin. Actually I can't understand why you
> want another mark(or tag) for tasks if we already have it and it's called
> role.
>
> Thanks,
> Andriy
>
> On Wed, Jun 24, 2015 at 6:45 PM, Samuel Bartel <
> samuel.bartel.pro at gmail.com> wrote:
>
>> Julia,
>>
>> It is exactly what i was thinking. With such a mechanism we would be able
>> to define custom labels to apply different type of task on compute nodes
>> according to their labels. I add a comment on the review. As for now I
>> don't see how we would be able to create custom label from plugin. In such
>> a case we would have to make evolution on plugin engine part so we will
>> have to identify exact impact on the plugin feature
>>
>> regards
>>
>> Samuel
>>
>> 2015-06-24 13:54 GMT+02:00 Julia Aranovich <jkirnosova at mirantis.com>:
>>
>>> Samuel, I would like you to consider this proposal:
>>> https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst
>>>
>>> This is about support of custom node labels. I think plugins should be
>>> able to assign its own labels to nodes via Nailgun API. Is it possible?
>>> Will it suit your case?
>>>
>>> Thanks,
>>> Julia
>>>
>>>
>>>
>>> On Wed, Jun 24, 2015 at 1:14 PM Samuel Bartel <
>>> samuel.bartel.pro at gmail.com> wrote:
>>>
>>>> Irina,
>>>>
>>>> Thanks for the link. Unfortunatly it does not cover my use cases. What
>>>> we would like to do is not define a new role.
>>>> We would like to be able to apply plugin to some compute node for
>>>> example and not in the others compute nodes or to be able to execute plugin
>>>> with a given config on some compute nodes and with an other config on other
>>>> compute nodes
>>>>
>>>> It is related to a capcity to tag/flag nodes and not adding new role
>>>>
>>>> regards
>>>>
>>>> Samuel
>>>>
>>>> 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya <
>>>> ipovolotskaya at mirantis.com>:
>>>>
>>>>> Samuel,
>>>>>
>>>>> Currently, there is a spec on introducing a new role through a plugin
>>>>> [1] - the feature is targeted at 7.0.
>>>>>
>>>>> Feel free to comment on it and ask questions right in the commit.
>>>>>
>>>>> [1] https://review.openstack.org/#/c/185267/
>>>>> --
>>>>> Best regards,
>>>>>
>>>>> Irina
>>>>>
>>>>> Partner Management Business Analyst
>>>>> skype: ira_live
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150624/43cbd8e3/attachment.html>