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 <akasat...@mirantis.com> написав(ла): > > 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 > <mailto: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 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 > <https://review.openstack.org/#/c/273169/1> > > On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko <adide...@mirantis.com > <mailto:adide...@mirantis.com>> 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 > <mailto: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 > <mailto: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 > <mailto: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 > <mailto:vkuk...@mirantis.com>> wrote: > +1 to overriding VIPs > > On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko <m...@romcheg.me > <mailto:m...@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 > > <https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55> > 2. http://xsnippet.org/361361/ <http://xsnippet.org/361361/> > 3. https://review.openstack.org/#/c/273169/1 > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 <tel:%2B7%20%28495%29%20640-49-04> > +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68> > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com <http://www.mirantis.ru/> > www.mirantis.ru <http://www.mirantis.ru/> > vkuk...@mirantis.com <mailto:vkuk...@mirantis.com> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
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
