Hi.
On 2024-08-09 (Fr.) 17:24, Willy Tarreau wrote:
Hi all,
I'm continuing to find disgusting things in the code that are only here
for historical reasons which, in my opinion, should no longer exist.
[snipp]
Now we're at an era where many configs are generated in ways that cannot
even produce such corner cases, they're harder to follow and debug, and
I'm wondering what's the point of preserving support for such cases which
I'm intimately convinced that nobody relies on.
I'd be interested in opinions on some of these options:
- deprecate duplicate server names for 3.1, requiring a global option
to support them and drop their support for 3.3 ?
I would vote for this option.
+1
- just drop the support of duplicate server names right now in 3.1 ?
- keep these working "forever" and reconsider the option later, due to
a very valid case that I'm ignoring ?
- for backends + frontends, deprecate same names in 3.1, drop in 3.3,
or drop now ? Or keep them ?
As you know I'm not in favor of removing stuff without prior warnings,
but these ones have become so absurd over time that sometimes I really
doubt anyone will ever run the code that deals with the error and the
code that parses the new option to force supporting the mechanism. We
could even consider backporting a warning for such cases in 3.0 so as
to limit the surprise if we were to drop that right now.
A warning for 3.0 is a good Idea, IMHO.
And I don't want to scare anyone, if there are valid cases, that's fine
as well and then I just want that we properly support them. It's just
that I feel that fixing the corner cases and costs above is pointless,
and without a use case I'm not tempted by investing time there.
If you're aware of other types of stupid duplicate identifiers that we
continue to support for historical reasons and that would make sense to
be simplified, please suggest!
Thanks in advance for sharing your opinion on this topic.
Willy
Regards
Alex
PS: let's also Cc Marko for the dataplane API since it should have impacts
on it, though very likely it will simplify it, not make it more complex.
PPS: no emergency if you're on holiday, we can decide in a month as well.
PPPS: please no delirium about how we should take this opportunity to
revist all the config language ;-)
