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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> wrote: >> >>> +1 to overriding VIPs >>> >>> -- >>> Best regards, >>> Sergii Golovatiuk, >>> Skype #golserge >>> IRC #holser >>> >>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <[email protected]> >>> wrote: >>> >>>> +1 to overriding VIPs >>>> >>>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko <[email protected]> >>>> 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: >>>>> [email protected]?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 >>>> [email protected] >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
