Guys,
I suppose that any solution for the plugins merge ordering issue (either
alerting about error or allowing user to manually set order) would be very
helpful and much better then no solution at all (like we currently have).
Maybe we should create a blueprint to not miss/forget about it?
This is basically why I proposed to allow users to set per cluster priority for
every enabled plugin. That would allow users to select results they need.
Putting too many logic into checks whether two plugins are incompatible is
error-prone and won’t stop anyone from shooting their feet.
> 29
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.
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?
> 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 wrote:
> Frankly, I
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
> 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
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 wrote:
> +1
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
wrote:
> Good idea, overally.
>
> How about multiple plugins? We don't have any sequence or
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?).
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
+1 to overriding VIPs
On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 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
+1 to overriding VIPs
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin
wrote:
> +1 to overriding VIPs
>
> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko
> wrote:
>
>> Folks,
>>
>>
13 matches
Mail list logo