Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksandr Didenko]

Guys,

I suppose that any solution for the plugins merge ordering issue (either
alerting about error or allowing user to manually set order) would be very
helpful and much better then no solution at all (like we currently have).
Maybe we should create a blueprint to not miss/forget about it?

Regards,
Alex

On Mon, Feb 1, 2016 at 6:10 PM, Roman Prykhodchenko  wrote:

> This is basically why I proposed to allow users to set per cluster
> priority for every enabled plugin. That would allow users to select results
> they need. Putting too many logic into checks whether two plugins are
> incompatible is error-prone and won’t stop anyone from shooting their feet.
>
>
> > 29 січ. 2016 р. о 16:10 Igor Kalnitsky 
> написав(ла):
> >
> > Roman P. wrote:
> >> Putting extra checks will create a more fool-proof but less configurable
> >> software. I’d vote for letting users shoot their feet using their
> plugins
> >> but making Fuel more flexible.
> >
> > I won't agree here. You see, what if two plugins wants to override the
> > core network role? Consider that plugin A wants to extend VIPs:
> >
> >id: "mgmt/vip"
> >default_mapping: "management"
> >properties:
> >  vip:
> >- name: "management"
> >  namespace: "haproxy"
> ># new VIP we want to add
> >- name: "myvip"
> >  namespace: "haproxy"
> >
> > while plugin B wants to remove them:
> >
> >id: "mgmt/vip"
> >default_mapping: "management"
> >properties:
> >  vip: []
> >
> > How do you suppose to resolve this action? We don't know in which
> > order they will be resolved, and I'm strongly against unpredictable
> > situation (especiall it may be different time-to-time and depends on
> > which order plugins will be selected).
> >
> > Moreover, it makes a little sense to try to resolve this situation. If
> > two plugins change something in core, they are probably incompatible.
> > Manual actions are required.
> >
> > So that's, basically, why I think we should warn user about
> > incompatible changes to core stuff. Just like we do for deployment
> > tasks.
> >
> > - igor
> >
> > On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko 
> wrote:
> >> I would not check that. We are not talking about installing browser
> plugins
> >> when users may not know what they want. Putting extra checks will
> create a
> >> more fool-proof but less configurable software. I’d vote for letting
> users
> >> shoot their feet using their plugins but making Fuel more flexible.
> >>
> >>
> >> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
> >> написав(ла):
> >>
> >>> jsonpatch
> >>
> >> There were +1's regarding overriding VIPs above. I'd stick with that.
> It is
> >> done for tasks now. But we will need to check conflicts between plugins
> >> there (as for tasks).
> >>
> >>
> >> Aleksey Kasatkin
> >>
> >>
> >> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko 
> wrote:
> >>>
> >>> Frankly, I have not though about how to deal with multiple plugins yet.
> >>> However, what I think is that we must not restrict this too much and
> let
> >>> users configure it more flexibly even if it allows to shoot one’s foot.
> >>> Perhaps we can add a per-cluster priority for enabled plugins which
> users
> >>> can configure via UI, CLI or API. My other thought is that we should
> not
> >>> invent our own mechanics for changing a configuration and use an
> existing
> >>> one, say, jsonpatch. What do you guys think?
> >>>
> >>> P. S. [0] is really needed for 8.0 for implementing an important epic,
> so
> >>> please check it out. If it does not break anything, lets merge it ASAP.
> >>>
> >>> - romcheg
> >>>
> >>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
> >>> написав(ла):
> >>>
> >>> AFAIC, it is better to remove by name then. Otherwise, you do not know
> >>> what VIPs you are removing.
> >>> Another option - remove "built-in" VIPs using some specific expression.
> >>> Anyway, you do not know where other VIPs (VIPs of other plugins) live
> so
> >>> you cannot remove them this way.
> >>>
> >>> And the order of plugins processing is not defined so there is no
> warranty
> >>> you will remove all VIPs on those network roles.
> >>> Seems, checking for such conflict between plugins is needed.
> >>>
> >>> The original goal, actually, was to remove VIPs for controllers (or for
> >>> some particular node role, maybe),
> >>> so we should maybe find a way to do exactly this.
> >>>
> >>>
> >>>
> >>> Aleksey Kasatkin
> >>>
> >>>
> >>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko <
> adide...@mirantis.com>
> >>> wrote:
> 
> > How are we handling this now for multiple plugins?
> 
>  OK, so right now we can only add VIPs to array, we can't remove them.
> So
>  overriding would disable such possibility of adding VIPs from
> different
>  plugins. But with [0] patch it will be still possible to add and to
> 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

This is basically why I proposed to allow users to set per cluster priority for 
every enabled plugin. That would allow users to select results they need. 
Putting too many logic into checks whether two plugins are incompatible is 
error-prone and won’t stop anyone from shooting their feet.


> 29 січ. 2016 р. о 16:10 Igor Kalnitsky  написав(ла):
> 
> Roman P. wrote:
>> Putting extra checks will create a more fool-proof but less configurable
>> software. I’d vote for letting users shoot their feet using their plugins
>> but making Fuel more flexible.
> 
> I won't agree here. You see, what if two plugins wants to override the
> core network role? Consider that plugin A wants to extend VIPs:
> 
>id: "mgmt/vip"
>default_mapping: "management"
>properties:
>  vip:
>- name: "management"
>  namespace: "haproxy"
># new VIP we want to add
>- name: "myvip"
>  namespace: "haproxy"
> 
> while plugin B wants to remove them:
> 
>id: "mgmt/vip"
>default_mapping: "management"
>properties:
>  vip: []
> 
> How do you suppose to resolve this action? We don't know in which
> order they will be resolved, and I'm strongly against unpredictable
> situation (especiall it may be different time-to-time and depends on
> which order plugins will be selected).
> 
> Moreover, it makes a little sense to try to resolve this situation. If
> two plugins change something in core, they are probably incompatible.
> Manual actions are required.
> 
> So that's, basically, why I think we should warn user about
> incompatible changes to core stuff. Just like we do for deployment
> tasks.
> 
> - igor
> 
> On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko  wrote:
>> I would not check that. We are not talking about installing browser plugins
>> when users may not know what they want. Putting extra checks will create a
>> more fool-proof but less configurable software. I’d vote for letting users
>> shoot their feet using their plugins but making Fuel more flexible.
>> 
>> 
>> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
>> написав(ла):
>> 
>>> jsonpatch
>> 
>> There were +1's regarding overriding VIPs above. I'd stick with that. It is
>> done for tasks now. But we will need to check conflicts between plugins
>> there (as for tasks).
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:
>>> 
>>> Frankly, I have not though about how to deal with multiple plugins yet.
>>> However, what I think is that we must not restrict this too much and let
>>> users configure it more flexibly even if it allows to shoot one’s foot.
>>> Perhaps we can add a per-cluster priority for enabled plugins which users
>>> can configure via UI, CLI or API. My other thought is that we should not
>>> invent our own mechanics for changing a configuration and use an existing
>>> one, say, jsonpatch. What do you guys think?
>>> 
>>> P. S. [0] is really needed for 8.0 for implementing an important epic, so
>>> please check it out. If it does not break anything, lets merge it ASAP.
>>> 
>>> - romcheg
>>> 
>>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
>>> написав(ла):
>>> 
>>> AFAIC, it is better to remove by name then. Otherwise, you do not know
>>> what VIPs you are removing.
>>> Another option - remove "built-in" VIPs using some specific expression.
>>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
>>> you cannot remove them this way.
>>> 
>>> And the order of plugins processing is not defined so there is no warranty
>>> you will remove all VIPs on those network roles.
>>> Seems, checking for such conflict between plugins is needed.
>>> 
>>> The original goal, actually, was to remove VIPs for controllers (or for
>>> some particular node role, maybe),
>>> so we should maybe find a way to do exactly this.
>>> 
>>> 
>>> 
>>> Aleksey Kasatkin
>>> 
>>> 
>>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
>>> wrote:
 
> How are we handling this now for multiple plugins?
 
 OK, so right now we can only add VIPs to array, we can't remove them. So
 overriding would disable such possibility of adding VIPs from different
 plugins. But with [0] patch it will be still possible to add and to remove
 by providing empty array. But we'll have the problem with multiple plugins
 in such case.
 I've changed my mind :) I vote for leaving as in [0] since it's less
 destructive comparing to what we have now.
 
 Regards,
 Alex
 
 [0] https://review.openstack.org/#/c/273169/1
 
 On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko
  wrote:
> 
> Well, with merging instead of overriding, I believe, this problem with
> multiple plugins still exists, right? How are we handling this now for
> multiple plugins?
> Since VIPs is 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

I would not check that. We are not talking about installing browser plugins 
when users may not know what they want. Putting extra checks will create a more 
fool-proof but less configurable software. I’d vote for letting users shoot 
their feet using their plugins but making Fuel more flexible.


> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin  написав(ла):
> 
> > jsonpatch
> 
> There were +1's regarding overriding VIPs above. I'd stick with that. It is 
> done for tasks now. But we will need to check conflicts between plugins there 
> (as for tasks).
> 
> 
> Aleksey Kasatkin
> 
> 
> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  > wrote:
> Frankly, I have not though about how to deal with multiple plugins yet. 
> However, what I think is that we must not restrict this too much and let 
> users configure it more flexibly even if it allows to shoot one’s foot. 
> Perhaps we can add a per-cluster priority for enabled plugins which users can 
> configure via UI, CLI or API. My other thought is that we should not invent 
> our own mechanics for changing a configuration and use an existing one, say, 
> jsonpatch. What do you guys think?
> 
> P. S. [0] is really needed for 8.0 for implementing an important epic, so 
> please check it out. If it does not break anything, lets merge it ASAP.
> 
> - romcheg
> 
>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin > > написав(ла):
>> 
>> AFAIC, it is better to remove by name then. Otherwise, you do not know what 
>> VIPs you are removing.
>> Another option - remove "built-in" VIPs using some specific expression.
>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so you 
>> cannot remove them this way.
>> 
>> And the order of plugins processing is not defined so there is no warranty 
>> you will remove all VIPs on those network roles.
>> Seems, checking for such conflict between plugins is needed.
>> 
>> The original goal, actually, was to remove VIPs for controllers (or for some 
>> particular node role, maybe),
>> so we should maybe find a way to do exactly this.
>> 
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko > > wrote:
>> > How are we handling this now for multiple plugins?
>> 
>> OK, so right now we can only add VIPs to array, we can't remove them. So 
>> overriding would disable such possibility of adding VIPs from different 
>> plugins. But with [0] patch it will be still possible to add and to remove 
>> by providing empty array. But we'll have the problem with multiple plugins 
>> in such case.
>> I've changed my mind :) I vote for leaving as in [0] since it's less 
>> destructive comparing to what we have now.
>> 
>> Regards,
>> Alex
>> 
>> [0] https://review.openstack.org/#/c/273169/1 
>> 
>> 
>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko > > wrote:
>> Well, with merging instead of overriding, I believe, this problem with 
>> multiple plugins still exists, right? How are we handling this now for 
>> multiple plugins?
>> Since VIPs is array I also vote for overriding, since merging it could be a 
>> pain (how do you remove existing element during array merge?).
>> 
>> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin > > wrote:
>> Roman, please provide more details on how VIPs are overridden. And how do 
>> you deal with multiple plugins.
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin > > wrote:
>> Good idea, overally.
>> 
>> How about multiple plugins? We don't have any sequence or priorities between 
>> them.
>> What if one plugin assumes that VIP is present but other one wants to remove 
>> it?
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk > > wrote:
>> +1 to overriding VIPs
>> 
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>> 
>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin > > wrote:
>> +1 to overriding VIPs
>> 
>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko > > wrote:
>> Folks,
>> 
>> currently merge policy for network roles only allows to add new VIPs to 
>> already existing roles [1]. If a plugin supplies a VIP with a name that 
>> already exists but with different parameters, Nailgun will not allow to do 
>> that. We faced a need to override configuration of several VIPs by 
>> completely removing them from network roles by supplying something like [2]. 
>> To enable that I’ve made a temporary workaround [3] to 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Igor Kalnitsky]

Roman P. wrote:
> Putting extra checks will create a more fool-proof but less configurable
> software. I’d vote for letting users shoot their feet using their plugins
> but making Fuel more flexible.

I won't agree here. You see, what if two plugins wants to override the
core network role? Consider that plugin A wants to extend VIPs:

id: "mgmt/vip"
default_mapping: "management"
properties:
  vip:
- name: "management"
  namespace: "haproxy"
# new VIP we want to add
- name: "myvip"
  namespace: "haproxy"

while plugin B wants to remove them:

id: "mgmt/vip"
default_mapping: "management"
properties:
  vip: []

How do you suppose to resolve this action? We don't know in which
order they will be resolved, and I'm strongly against unpredictable
situation (especiall it may be different time-to-time and depends on
which order plugins will be selected).

Moreover, it makes a little sense to try to resolve this situation. If
two plugins change something in core, they are probably incompatible.
Manual actions are required.

So that's, basically, why I think we should warn user about
incompatible changes to core stuff. Just like we do for deployment
tasks.

- igor

On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko  wrote:
> I would not check that. We are not talking about installing browser plugins
> when users may not know what they want. Putting extra checks will create a
> more fool-proof but less configurable software. I’d vote for letting users
> shoot their feet using their plugins but making Fuel more flexible.
>
>
> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
> написав(ла):
>
>> jsonpatch
>
> There were +1's regarding overriding VIPs above. I'd stick with that. It is
> done for tasks now. But we will need to check conflicts between plugins
> there (as for tasks).
>
>
> Aleksey Kasatkin
>
>
> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:
>>
>> Frankly, I have not though about how to deal with multiple plugins yet.
>> However, what I think is that we must not restrict this too much and let
>> users configure it more flexibly even if it allows to shoot one’s foot.
>> Perhaps we can add a per-cluster priority for enabled plugins which users
>> can configure via UI, CLI or API. My other thought is that we should not
>> invent our own mechanics for changing a configuration and use an existing
>> one, say, jsonpatch. What do you guys think?
>>
>> P. S. [0] is really needed for 8.0 for implementing an important epic, so
>> please check it out. If it does not break anything, lets merge it ASAP.
>>
>> - romcheg
>>
>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
>> написав(ла):
>>
>> AFAIC, it is better to remove by name then. Otherwise, you do not know
>> what VIPs you are removing.
>> Another option - remove "built-in" VIPs using some specific expression.
>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
>> you cannot remove them this way.
>>
>> And the order of plugins processing is not defined so there is no warranty
>> you will remove all VIPs on those network roles.
>> Seems, checking for such conflict between plugins is needed.
>>
>> The original goal, actually, was to remove VIPs for controllers (or for
>> some particular node role, maybe),
>> so we should maybe find a way to do exactly this.
>>
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
>> wrote:
>>>
>>> > How are we handling this now for multiple plugins?
>>>
>>> OK, so right now we can only add VIPs to array, we can't remove them. So
>>> overriding would disable such possibility of adding VIPs from different
>>> plugins. But with [0] patch it will be still possible to add and to remove
>>> by providing empty array. But we'll have the problem with multiple plugins
>>> in such case.
>>> I've changed my mind :) I vote for leaving as in [0] since it's less
>>> destructive comparing to what we have now.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/c/273169/1
>>>
>>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko
>>>  wrote:

 Well, with merging instead of overriding, I believe, this problem with
 multiple plugins still exists, right? How are we handling this now for
 multiple plugins?
 Since VIPs is array I also vote for overriding, since merging it could
 be a pain (how do you remove existing element during array merge?).

 On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin
  wrote:
>
> Roman, please provide more details on how VIPs are overridden. And how
> do you deal with multiple plugins.
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin
>  wrote:
>>
>> Good idea, overally.
>>
>> How 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksey Kasatkin]

> jsonpatch

There were +1's regarding overriding VIPs above. I'd stick with that. It is
done for tasks now. But we will need to check conflicts between plugins
there (as for tasks).


Aleksey Kasatkin


On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:

> Frankly, I have not though about how to deal with multiple plugins yet.
> However, what I think is that we must not restrict this too much and let
> users configure it more flexibly even if it allows to shoot one’s foot.
> Perhaps we can add a per-cluster priority for enabled plugins which users
> can configure via UI, CLI or API. My other thought is that we should not
> invent our own mechanics for changing a configuration and use an existing
> one, say, jsonpatch. What do you guys think?
>
> P. S. [0] is really needed for 8.0 for implementing an important epic, so
> please check it out. If it does not break anything, lets merge it ASAP.
>
> - romcheg
>
> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
> написав(ла):
>
> AFAIC, it is better to remove by name then. Otherwise, you do not know
> what VIPs you are removing.
> Another option - remove "built-in" VIPs using some specific expression.
> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
> you cannot remove them this way.
>
> And the order of plugins processing is not defined so there is no warranty
> you will remove all VIPs on those network roles.
> Seems, checking for such conflict between plugins is needed.
>
> The original goal, actually, was to remove VIPs for controllers (or for
> some particular node role, maybe),
> so we should maybe find a way to do exactly this.
>
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
> wrote:
>
>> > How are we handling this now for multiple plugins?
>>
>> OK, so right now we can only add VIPs to array, we can't remove them. So
>> overriding would disable such possibility of adding VIPs from different
>> plugins. But with [0] patch it will be still possible to add and to remove
>> by providing empty array. But we'll have the problem with multiple plugins
>> in such case.
>> I've changed my mind :) I vote for leaving as in [0] since it's less
>> destructive comparing to what we have now.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/273169/1
>>
>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko > > wrote:
>>
>>> Well, with merging instead of overriding, I believe, this problem with
>>> multiple plugins still exists, right? How are we handling this now for
>>> multiple plugins?
>>> Since VIPs is array I also vote for overriding, since merging it could
>>> be a pain (how do you remove existing element during array merge?).
>>>
>>> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin <
>>> akasat...@mirantis.com> wrote:
>>>
 Roman, please provide more details on how VIPs are overridden. And how
 do you deal with multiple plugins.


 Aleksey Kasatkin


 On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin <
 akasat...@mirantis.com> wrote:

> Good idea, overally.
>
> How about multiple plugins? We don't have any sequence or priorities
> between them.
> What if one plugin assumes that VIP is present but other one wants to
> remove it?
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> +1 to overriding VIPs
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <
>> vkuk...@mirantis.com> wrote:
>>
>>> +1 to overriding VIPs
>>>
>>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
>>> wrote:
>>>
 Folks,

 currently merge policy for network roles only allows to add new
 VIPs to already existing roles [1]. If a plugin supplies a VIP with a 
 name
 that already exists but with different parameters, Nailgun will not 
 allow
 to do that. We faced a need to override configuration of several VIPs 
 by
 completely removing them from network roles by supplying something like
 [2]. To enable that I’ve made a temporary workaround [3] to the merging
 policy that only handles one cornerstone.

 I’ve talked to ikalnitsky and we realized that this functionality
 of merging new VIPs from plugins to an existing network role is 
 actually
 wrong and should be replaced by complete overriding. Let’s discuss this
 possibility here.


 References:

 1.
 https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
 2. http://xsnippet.org/361361/
 3. 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

Frankly, I have not though about how to deal with multiple plugins yet. 
However, what I think is that we must not restrict this too much and let users 
configure it more flexibly even if it allows to shoot one’s foot. Perhaps we 
can add a per-cluster priority for enabled plugins which users can configure 
via UI, CLI or API. My other thought is that we should not invent our own 
mechanics for changing a configuration and use an existing one, say, jsonpatch. 
What do you guys think?

P. S. [0] is really needed for 8.0 for implementing an important epic, so 
please check it out. If it does not break anything, lets merge it ASAP.

- romcheg

> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin  написав(ла):
> 
> AFAIC, it is better to remove by name then. Otherwise, you do not know what 
> VIPs you are removing.
> Another option - remove "built-in" VIPs using some specific expression.
> Anyway, you do not know where other VIPs (VIPs of other plugins) live so you 
> cannot remove them this way.
> 
> And the order of plugins processing is not defined so there is no warranty 
> you will remove all VIPs on those network roles.
> Seems, checking for such conflict between plugins is needed.
> 
> The original goal, actually, was to remove VIPs for controllers (or for some 
> particular node role, maybe),
> so we should maybe find a way to do exactly this.
> 
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko  > wrote:
> > How are we handling this now for multiple plugins?
> 
> OK, so right now we can only add VIPs to array, we can't remove them. So 
> overriding would disable such possibility of adding VIPs from different 
> plugins. But with [0] patch it will be still possible to add and to remove by 
> providing empty array. But we'll have the problem with multiple plugins in 
> such case.
> I've changed my mind :) I vote for leaving as in [0] since it's less 
> destructive comparing to what we have now.
> 
> Regards,
> Alex
> 
> [0] https://review.openstack.org/#/c/273169/1 
> 
> 
> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko  > wrote:
> Well, with merging instead of overriding, I believe, this problem with 
> multiple plugins still exists, right? How are we handling this now for 
> multiple plugins?
> Since VIPs is array I also vote for overriding, since merging it could be a 
> pain (how do you remove existing element during array merge?).
> 
> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin  > wrote:
> Roman, please provide more details on how VIPs are overridden. And how do you 
> deal with multiple plugins.
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin  > wrote:
> Good idea, overally.
> 
> How about multiple plugins? We don't have any sequence or priorities between 
> them.
> What if one plugin assumes that VIP is present but other one wants to remove 
> it?
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk  > wrote:
> +1 to overriding VIPs
> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin  > wrote:
> +1 to overriding VIPs
> 
> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko  > wrote:
> Folks,
> 
> currently merge policy for network roles only allows to add new VIPs to 
> already existing roles [1]. If a plugin supplies a VIP with a name that 
> already exists but with different parameters, Nailgun will not allow to do 
> that. We faced a need to override configuration of several VIPs by completely 
> removing them from network roles by supplying something like [2]. To enable 
> that I’ve made a temporary workaround [3] to the merging policy that only 
> handles one cornerstone.
> 
> I’ve talked to ikalnitsky and we realized that this functionality of merging 
> new VIPs from plugins to an existing network role is actually wrong and 
> should be replaced by complete overriding. Let’s discuss this possibility 
> here.
> 
> 
> References:
> 
> 1. 
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>  
> 
> 2. http://xsnippet.org/361361/ 
> 3. https://review.openstack.org/#/c/273169/1 
> 
> 
> 
> - romcheg
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksandr Didenko]

> How are we handling this now for multiple plugins?

OK, so right now we can only add VIPs to array, we can't remove them. So
overriding would disable such possibility of adding VIPs from different
plugins. But with [0] patch it will be still possible to add and to remove
by providing empty array. But we'll have the problem with multiple plugins
in such case.
I've changed my mind :) I vote for leaving as in [0] since it's less
destructive comparing to what we have now.

Regards,
Alex

[0] https://review.openstack.org/#/c/273169/1

On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko 
wrote:

> Well, with merging instead of overriding, I believe, this problem with
> multiple plugins still exists, right? How are we handling this now for
> multiple plugins?
> Since VIPs is array I also vote for overriding, since merging it could be
> a pain (how do you remove existing element during array merge?).
>
> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin 
> wrote:
>
>> Roman, please provide more details on how VIPs are overridden. And how do
>> you deal with multiple plugins.
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin > > wrote:
>>
>>> Good idea, overally.
>>>
>>> How about multiple plugins? We don't have any sequence or priorities
>>> between them.
>>> What if one plugin assumes that VIP is present but other one wants to
>>> remove it?
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>>
>>> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>>
 +1 to overriding VIPs

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin  wrote:

> +1 to overriding VIPs
>
> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
> wrote:
>
>> Folks,
>>
>> currently merge policy for network roles only allows to add new VIPs
>> to already existing roles [1]. If a plugin supplies a VIP with a name 
>> that
>> already exists but with different parameters, Nailgun will not allow to 
>> do
>> that. We faced a need to override configuration of several VIPs by
>> completely removing them from network roles by supplying something like
>> [2]. To enable that I’ve made a temporary workaround [3] to the merging
>> policy that only handles one cornerstone.
>>
>> I’ve talked to ikalnitsky and we realized that this functionality of
>> merging new VIPs from plugins to an existing network role is actually 
>> wrong
>> and should be replaced by complete overriding. Let’s discuss this
>> possibility here.
>>
>>
>> References:
>>
>> 1.
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>> 2. http://xsnippet.org/361361/
>> 3. https://review.openstack.org/#/c/273169/1
>>
>>
>> - romcheg
>>
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
>
> __
> 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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksey Kasatkin]

Good idea, overally.

How about multiple plugins? We don't have any sequence or priorities
between them.
What if one plugin assumes that VIP is present but other one wants to
remove it?


Aleksey Kasatkin


On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk  wrote:

> +1 to overriding VIPs
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin 
> wrote:
>
>> +1 to overriding VIPs
>>
>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
>> wrote:
>>
>>> Folks,
>>>
>>> currently merge policy for network roles only allows to add new VIPs to
>>> already existing roles [1]. If a plugin supplies a VIP with a name that
>>> already exists but with different parameters, Nailgun will not allow to do
>>> that. We faced a need to override configuration of several VIPs by
>>> completely removing them from network roles by supplying something like
>>> [2]. To enable that I’ve made a temporary workaround [3] to the merging
>>> policy that only handles one cornerstone.
>>>
>>> I’ve talked to ikalnitsky and we realized that this functionality of
>>> merging new VIPs from plugins to an existing network role is actually wrong
>>> and should be replaced by complete overriding. Let’s discuss this
>>> possibility here.
>>>
>>>
>>> References:
>>>
>>> 1.
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>>> 2. http://xsnippet.org/361361/
>>> 3. https://review.openstack.org/#/c/273169/1
>>>
>>>
>>> - romcheg
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> 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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksey Kasatkin]

Roman, please provide more details on how VIPs are overridden. And how do
you deal with multiple plugins.


Aleksey Kasatkin


On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin 
wrote:

> Good idea, overally.
>
> How about multiple plugins? We don't have any sequence or priorities
> between them.
> What if one plugin assumes that VIP is present but other one wants to
> remove it?
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> +1 to overriding VIPs
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin 
>> wrote:
>>
>>> +1 to overriding VIPs
>>>
>>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
>>> wrote:
>>>
 Folks,

 currently merge policy for network roles only allows to add new VIPs to
 already existing roles [1]. If a plugin supplies a VIP with a name that
 already exists but with different parameters, Nailgun will not allow to do
 that. We faced a need to override configuration of several VIPs by
 completely removing them from network roles by supplying something like
 [2]. To enable that I’ve made a temporary workaround [3] to the merging
 policy that only handles one cornerstone.

 I’ve talked to ikalnitsky and we realized that this functionality of
 merging new VIPs from plugins to an existing network role is actually wrong
 and should be replaced by complete overriding. Let’s discuss this
 possibility here.


 References:

 1.
 https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
 2. http://xsnippet.org/361361/
 3. https://review.openstack.org/#/c/273169/1


 - romcheg



 __
 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


>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> 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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksandr Didenko]

Well, with merging instead of overriding, I believe, this problem with
multiple plugins still exists, right? How are we handling this now for
multiple plugins?
Since VIPs is array I also vote for overriding, since merging it could be a
pain (how do you remove existing element during array merge?).

On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin 
wrote:

> Roman, please provide more details on how VIPs are overridden. And how do
> you deal with multiple plugins.
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin 
> wrote:
>
>> Good idea, overally.
>>
>> How about multiple plugins? We don't have any sequence or priorities
>> between them.
>> What if one plugin assumes that VIP is present but other one wants to
>> remove it?
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> +1 to overriding VIPs
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin 
>>> wrote:
>>>
 +1 to overriding VIPs

 On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
 wrote:

> Folks,
>
> currently merge policy for network roles only allows to add new VIPs
> to already existing roles [1]. If a plugin supplies a VIP with a name that
> already exists but with different parameters, Nailgun will not allow to do
> that. We faced a need to override configuration of several VIPs by
> completely removing them from network roles by supplying something like
> [2]. To enable that I’ve made a temporary workaround [3] to the merging
> policy that only handles one cornerstone.
>
> I’ve talked to ikalnitsky and we realized that this functionality of
> merging new VIPs from plugins to an existing network role is actually 
> wrong
> and should be replaced by complete overriding. Let’s discuss this
> possibility here.
>
>
> References:
>
> 1.
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
> 2. http://xsnippet.org/361361/
> 3. https://review.openstack.org/#/c/273169/1
>
>
> - romcheg
>
>
>
> __
> 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
>
>


 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com 
 www.mirantis.ru
 vkuk...@mirantis.com


 __
 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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Aleksey Kasatkin]

AFAIC, it is better to remove by name then. Otherwise, you do not know what
VIPs you are removing.
Another option - remove "built-in" VIPs using some specific expression.
Anyway, you do not know where other VIPs (VIPs of other plugins) live so
you cannot remove them this way.

And the order of plugins processing is not defined so there is no warranty
you will remove all VIPs on those network roles.
Seems, checking for such conflict between plugins is needed.

The original goal, actually, was to remove VIPs for controllers (or for
some particular node role, maybe),
so we should maybe find a way to do exactly this.



Aleksey Kasatkin


On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
wrote:

> > How are we handling this now for multiple plugins?
>
> OK, so right now we can only add VIPs to array, we can't remove them. So
> overriding would disable such possibility of adding VIPs from different
> plugins. But with [0] patch it will be still possible to add and to remove
> by providing empty array. But we'll have the problem with multiple plugins
> in such case.
> I've changed my mind :) I vote for leaving as in [0] since it's less
> destructive comparing to what we have now.
>
> Regards,
> Alex
>
> [0] https://review.openstack.org/#/c/273169/1
>
> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko 
> wrote:
>
>> Well, with merging instead of overriding, I believe, this problem with
>> multiple plugins still exists, right? How are we handling this now for
>> multiple plugins?
>> Since VIPs is array I also vote for overriding, since merging it could be
>> a pain (how do you remove existing element during array merge?).
>>
>> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin > > wrote:
>>
>>> Roman, please provide more details on how VIPs are overridden. And how
>>> do you deal with multiple plugins.
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>>
>>> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin <
>>> akasat...@mirantis.com> wrote:
>>>
 Good idea, overally.

 How about multiple plugins? We don't have any sequence or priorities
 between them.
 What if one plugin assumes that VIP is present but other one wants to
 remove it?


 Aleksey Kasatkin


 On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
 sgolovat...@mirantis.com> wrote:

> +1 to overriding VIPs
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <
> vkuk...@mirantis.com> wrote:
>
>> +1 to overriding VIPs
>>
>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
>> wrote:
>>
>>> Folks,
>>>
>>> currently merge policy for network roles only allows to add new VIPs
>>> to already existing roles [1]. If a plugin supplies a VIP with a name 
>>> that
>>> already exists but with different parameters, Nailgun will not allow to 
>>> do
>>> that. We faced a need to override configuration of several VIPs by
>>> completely removing them from network roles by supplying something like
>>> [2]. To enable that I’ve made a temporary workaround [3] to the merging
>>> policy that only handles one cornerstone.
>>>
>>> I’ve talked to ikalnitsky and we realized that this functionality of
>>> merging new VIPs from plugins to an existing network role is actually 
>>> wrong
>>> and should be replaced by complete overriding. Let’s discuss this
>>> possibility here.
>>>
>>>
>>> References:
>>>
>>> 1.
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>>> 2. http://xsnippet.org/361361/
>>> 3. https://review.openstack.org/#/c/273169/1
>>>
>>>
>>> - romcheg
>>>
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>>
>> __
>> 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-dev] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

Folks,

currently merge policy for network roles only allows to add new VIPs to already 
existing roles [1]. If a plugin supplies a VIP with a name that already exists 
but with different parameters, Nailgun will not allow to do that. We faced a 
need to override configuration of several VIPs by completely removing them from 
network roles by supplying something like [2]. To enable that I’ve made a 
temporary workaround [3] to the merging policy that only handles one 
cornerstone.

I’ve talked to ikalnitsky and we realized that this functionality of merging 
new VIPs from plugins to an existing network role is actually wrong and should 
be replaced by complete overriding. Let’s discuss this possibility here.


References:

1. 
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
2. http://xsnippet.org/361361/
3. https://review.openstack.org/#/c/273169/1


- romcheg



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Vladimir Kuklin]

+1 to overriding VIPs

On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko  wrote:

> Folks,
>
> currently merge policy for network roles only allows to add new VIPs to
> already existing roles [1]. If a plugin supplies a VIP with a name that
> already exists but with different parameters, Nailgun will not allow to do
> that. We faced a need to override configuration of several VIPs by
> completely removing them from network roles by supplying something like
> [2]. To enable that I’ve made a temporary workaround [3] to the merging
> policy that only handles one cornerstone.
>
> I’ve talked to ikalnitsky and we realized that this functionality of
> merging new VIPs from plugins to an existing network role is actually wrong
> and should be replaced by complete overriding. Let’s discuss this
> possibility here.
>
>
> References:
>
> 1.
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
> 2. http://xsnippet.org/361361/
> 3. https://review.openstack.org/#/c/273169/1
>
>
> - romcheg
>
>
> __
> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Sergii Golovatiuk]

+1 to overriding VIPs

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin 
wrote:

> +1 to overriding VIPs
>
> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
> wrote:
>
>> Folks,
>>
>> currently merge policy for network roles only allows to add new VIPs to
>> already existing roles [1]. If a plugin supplies a VIP with a name that
>> already exists but with different parameters, Nailgun will not allow to do
>> that. We faced a need to override configuration of several VIPs by
>> completely removing them from network roles by supplying something like
>> [2]. To enable that I’ve made a temporary workaround [3] to the merging
>> policy that only handles one cornerstone.
>>
>> I’ve talked to ikalnitsky and we realized that this functionality of
>> merging new VIPs from plugins to an existing network role is actually wrong
>> and should be replaced by complete overriding. Let’s discuss this
>> possibility here.
>>
>>
>> References:
>>
>> 1.
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>> 2. http://xsnippet.org/361361/
>> 3. https://review.openstack.org/#/c/273169/1
>>
>>
>> - romcheg
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> 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