Open Stack

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 <akasatkin at 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 <akasatkin at 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 <
>> sgolovatiuk at 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 <vkuklin at mirantis.com>
>>> wrote:
>>>
>>>> +1 to overriding VIPs
>>>>
>>>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko <me at romcheg.me>
>>>> 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-request at 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 <http://www.mirantis.ru/>
>>>> www.mirantis.ru
>>>> vkuklin at mirantis.com
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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/20160128/06a5cd31/attachment.html>