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