<div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>First, thank you all for your contributions on that topic (I don't know what it has been split in two thread but let reply on this one)<br></div>Igor : the problem I try to solve is the following, I would like to be able to :<br></div>1/decide on which compute node I want to deploy a plugin. for the example of nova-nfs, I would like to be able to keep lvm for ephemeral volume in some compute nodes and use the nova-nfs in others<br></div>2/be able to group compute nodes in order to apply a plugin with a different configuration for each group. My first use case here would be to be able to define and setup availability zone<br><br></div><div>I totaly agree that filtrering on node name is not a good solution (possible typo or other human errors)<br></div><div><br></div>What I understand/keep for the different contribution is that we have two very interesting  specs:<br>- <a href="https://review.openstack.org/#/c/185267/" target="_blank">https://review.openstack.org/#/c/185267/</a><span class=""><font color="#888888"> for new role definition<br></font></span></div><span class=""><font color="#888888"> </font></span><br><div>-<a href="https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst" target="_blank">https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst</a> for label definition<br><br></div><div>with these specs (maybe shipped in 7.0) this is how I think these use cases could be implemented<br></div><div>1/ with the new role definition, the plugin can define a new role nova-nfs and in task.yaml filtre on this new role. Then to apply a plugin in a given compute node user would have to check the nova-nfs checkbox in setttings tab and assign nova-nfs to the corresponding compute nodes<br></div><div>2/ with the label defitinion : the plugin can define new labels (corresponding to several availaibility zone. then user would have to activate the plugin by checking the box in the setttings tab and assign label. then the plugin with setup availability zone and assign compute nodes ccording to labels<br><br></div><div>The problem is that these feature are not expected at least before 7.0. That's why I am looking for a solution usuable right now with 6.0 and 6.1.<br></div><div>For the availability zone use case, we can, as suggested by Igor, introduce several fields for each availability zone and list uid of the node in each fields. Other solution would be to use the nodegroup feature to define 1 node group by desire availability zone <br></div><div>For the nova-nfs, i can't figure out perfect solution. one can be to use a "magic" word, as mentioned by Andrey, in the name but we already seen it would lead to lot of potential errors. the other one derived from Igor idea for az would be tlo have a fiel with the list of uid of the nodes on which we want to apply the nova-nfs configuration<br><br></div><div>regards<br><br></div><div>Samuel<br></div><div><br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-26 7:12 GMT+02:00 Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Samuel,<br>
<br>
Here's my 2 cents on this topic. First of all, I'd like to ask you -<br>
what problem do you try to solve? Please, answer on that first because<br>
it'll help me to come back with solution.<br>
<br>
Currently it looks like an error-prone approach to apply nova-nfs<br>
tasks only on roles with some label. Why? Because what if user forgot<br>
to attach them? Or he just made a typo here? It'd be better to<br>
introduce a special mixin-role (nova-nfs) where user explicitly assign<br>
it to those compute nodes he wants to use it.<br>
<br>
Regarding second issue, perhaps it would be useful affect deployment<br>
through labels.. but I'm not sure it'll be done in 7.0. What about<br>
plugin settings? You can introduce two fields: az1, az2, each is a<br>
list of node ids. You will be able to use this information during<br>
deployment, because afaik we serialize cluster attributes.<br>
<br>
Thanks,<br>
Igor<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jun 24, 2015 at 11:03 PM, Andriy Popovych<br>
<<a href="mailto:apopovych@mirantis.com">apopovych@mirantis.com</a>> wrote:<br>
> Samuel,<br>
><br>
> As I know one node can have many roles.<br>
><br>
> For 1/ You can specify custom nova-nfs role and assign it on compute nodes.<br>
><br>
> Regards,<br>
> Andriy<br>
><br>
> On Wed, Jun 24, 2015 at 10:21 PM, Samuel Bartel<br>
> <<a href="mailto:samuel.bartel.pro@gmail.com">samuel.bartel.pro@gmail.com</a>> wrote:<br>
>><br>
>> Andriy,<br>
>><br>
>> May be 'role' was not the correct word  here.<br>
>> For me role are compute, controller, base-os, cinder, mongo. I know that<br>
>> we can specify that a task A should be executed on some role (controller and<br>
>> compute for example) and a task B on some other roles (Cinder for example).<br>
>><br>
>> To come back to my previous examples with the label feature presented by<br>
>> Irina :<br>
>> 1/ not apply nova-nfs plugin in all compute nodes<br>
>> we would assign a label on the nodes on which we want to setup the nfs<br>
>> backend storage for ephemeral volume. Then in the deploymodule we would be<br>
>> able to put a condition to setup it or not. Here the cleaner solution would<br>
>> be in th task.yaml to define a condition to execute the task for a given<br>
>> role AND a given label (here role would be equal to compute and label could<br>
>> be equal to nfs)<br>
>><br>
>> 2/ a plugin to define availability zone:<br>
>> if I have 3 compute nodes, I would be able to assign az1 label to compute<br>
>> node 1  and 2 and label az2 to compute node 3. Then in the plugin deployment<br>
>> moduel I would be able to setup a az called az1 with compute nodes 1 and 2<br>
>> and a az called az2 with compute node 3. It is not custom role as these<br>
>> nodes are compute.<br>
>><br>
>><br>
>> regards<br>
>><br>
>> Samuel<br>
>><br>
>> 2015-06-24 20:20 GMT+02:00 Andriy Popovych <<a href="mailto:apopovych@mirantis.com">apopovych@mirantis.com</a>>:<br>
>>><br>
>>> Samuel,<br>
>>><br>
>>> AFAIK labels will not be related to tasks, it's just marks for filtering<br>
>>> nodes.<br>
>>> What "roles" means for you?<br>
>>><br>
>>> we have tasks (A, B, C, D) and on some nodes tasks A B D should be<br>
>>> executed, on some B C etc. So plugin can provide specials marks or tags or<br>
>>> sets (we call it "roles") and link<br>
>>> tasks with it. In example before we can describe roles 'a' and 'b' to<br>
>>> group 2 different sets of tasks ABD and BC. So A links with 'a', B with 'a'<br>
>>> and 'b', C with 'b' and D  with 'a'). Both roles 'a' and 'b' can be<br>
>>> implemented in context of ONE plugin. Actually I can't understand why you<br>
>>> want another mark(or tag) for tasks if we already have it and it's called<br>
>>> role.<br>
>>><br>
>>> Thanks,<br>
>>> Andriy<br>
>>><br>
>>> On Wed, Jun 24, 2015 at 6:45 PM, Samuel Bartel<br>
>>> <<a href="mailto:samuel.bartel.pro@gmail.com">samuel.bartel.pro@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Julia,<br>
>>>><br>
>>>> It is exactly what i was thinking. With such a mechanism we would be<br>
>>>> able to define custom labels to apply different type of task on compute<br>
>>>> nodes according to their labels. I add a comment on the review. As for now I<br>
>>>> don't see how we would be able to create custom label from plugin. In such a<br>
>>>> case we would have to make evolution on plugin engine part so we will have<br>
>>>> to identify exact impact on the plugin feature<br>
>>>><br>
>>>> regards<br>
>>>><br>
>>>> Samuel<br>
>>>><br>
>>>> 2015-06-24 13:54 GMT+02:00 Julia Aranovich <<a href="mailto:jkirnosova@mirantis.com">jkirnosova@mirantis.com</a>>:<br>
>>>>><br>
>>>>> Samuel, I would like you to consider this proposal:<br>
>>>>> <a href="https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst</a><br>
>>>>><br>
>>>>> This is about support of custom node labels. I think plugins should be<br>
>>>>> able to assign its own labels to nodes via Nailgun API. Is it possible? Will<br>
>>>>> it suit your case?<br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Julia<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Wed, Jun 24, 2015 at 1:14 PM Samuel Bartel<br>
>>>>> <<a href="mailto:samuel.bartel.pro@gmail.com">samuel.bartel.pro@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Irina,<br>
>>>>>><br>
>>>>>> Thanks for the link. Unfortunatly it does not cover my use cases. What<br>
>>>>>> we would like to do is not define a new role.<br>
>>>>>> We would like to be able to apply plugin to some compute node for<br>
>>>>>> example and not in the others compute nodes or to be able to execute plugin<br>
>>>>>> with a given config on some compute nodes and with an other config on other<br>
>>>>>> compute nodes<br>
>>>>>><br>
>>>>>> It is related to a capcity to tag/flag nodes and not adding new role<br>
>>>>>><br>
>>>>>> regards<br>
>>>>>><br>
>>>>>> Samuel<br>
>>>>>><br>
>>>>>> 2015-06-24 11:54 GMT+02:00 Irina Povolotskaya<br>
>>>>>> <<a href="mailto:ipovolotskaya@mirantis.com">ipovolotskaya@mirantis.com</a>>:<br>
>>>>>>><br>
>>>>>>> Samuel,<br>
>>>>>>><br>
>>>>>>> Currently, there is a spec on introducing a new role through a plugin<br>
>>>>>>> [1] - the feature is targeted at 7.0.<br>
>>>>>>><br>
>>>>>>> Feel free to comment on it and ask questions right in the commit.<br>
>>>>>>><br>
>>>>>>> [1] <a href="https://review.openstack.org/#/c/185267/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/185267/</a><br>
>>>>>>> --<br>
>>>>>>> Best regards,<br>
>>>>>>><br>
>>>>>>> Irina<br>
>>>>>>><br>
>>>>>>> Partner Management Business Analyst<br>
>>>>>>> skype: ira_live<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> __________________________________________________________________________<br>
>>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>>> Unsubscribe:<br>
>>>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> __________________________________________________________________________<br>
>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>