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 <apopov...@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....@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 <jkirnos...@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....@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 < >>>> ipovolotsk...@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-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 >>>> >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> > > __________________________________________________________________________ > 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
