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 <akasat...@mirantis.com> написав(ла): > > > 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 <m...@romcheg.me > <mailto:m...@romcheg.me>> 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 <akasat...@mirantis.com >> <mailto: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 >> <mailto: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
