Open Stack

Hi Samuel,

Here's my 2 cents on this topic. First of all, I'd like to ask you -
what problem do you try to solve? Please, answer on that first because
it'll help me to come back with solution.

Currently it looks like an error-prone approach to apply nova-nfs
tasks only on roles with some label. Why? Because what if user forgot
to attach them? Or he just made a typo here? It'd be better to
introduce a special mixin-role (nova-nfs) where user explicitly assign
it to those compute nodes he wants to use it.

Regarding second issue, perhaps it would be useful affect deployment
through labels.. but I'm not sure it'll be done in 7.0. What about
plugin settings? You can introduce two fields: az1, az2, each is a
list of node ids. You will be able to use this information during
deployment, because afaik we serialize cluster attributes.

Thanks,
Igor

On Wed, Jun 24, 2015 at 11:03 PM, Andriy Popovych
<apopovych at mirantis.com> wrote:
> Samuel,
>
> As I know one node can have many roles.
>
> For 1/ You can specify custom nova-nfs role and assign it on compute nodes.
>
> Regards,
> Andriy
>
> On Wed, Jun 24, 2015 at 10:21 PM, Samuel Bartel
> <samuel.bartel.pro at gmail.com> wrote:
>>
>> 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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>