Open Stack

Hi,

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)
Igor : the problem I try to solve is the following, I would like to be able
to :
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
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

I totaly agree that filtrering on node name is not a good solution
(possible typo or other human errors)

What I understand/keep for the different contribution is that we have two
very interesting  specs:
- https://review.openstack.org/#/c/185267/ for new role definition

-
https://review.openstack.org/#/c/184076/6/specs/7.0/node-custom-attributes.rst
for label definition

with these specs (maybe shipped in 7.0) this is how I think these use cases
could be implemented
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
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

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

regards

Samuel




2015-06-26 7:12 GMT+02:00 Igor Kalnitsky <ikalnitsky at mirantis.com>:

> 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
> >
>
> __________________________________________________________________________
> 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/20150626/450e8502/attachment.html>