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.
For example, we still support duplicate server names if they have an
explicit ID. Example:
# this is rejected
backend b
server s 127.0.0.1
server s 127.0.0.2
# this is accepted
backend b
server s 127.0.0.1 id 1
server s 127.0.0.2 id 2
The check to block the first one runs in O(N^2) at boot, though I
could turn it to O(N*log(N)) but I'm wondering if that's worth it.
There's even special code in "use-server" rules to deal with that, it
carefully scans all servers matching the name in their declaration
order, and checks for their state so that it returns the first working
one. TBH, I strongly doubt anyone relies on this, and I'd be tempted by
deprecating this feature first, then killing it after a few versions.
Another example: frontend/backend/listen name duplicate detection. It's
a bit awkward and actually bogus. The principle was to say that if a
proxy has a frontend capability (hence "frontend" or "listen"), then
we check for duplicate frontend names, and that if a proxy has a backend
capability (hence "backend" or "listen"), then we check for duplicate
backend names. It was incorrectly implemented as:
if the proxy has frontend capability, then
check_for_frontend_duplicate()
otherwise
check_for_backend_duplicate()
This results in this config to be incorrectly accepted:
backend b
listen b
bind :8888
Indeed, the second "b" has frontend capability, thus we search for another
frontend, there is none so that's OK. It definitely is an accident but it
perfectly illustrates the absurdity of the current situation.
At the very least I would like to fix that one but quite frankly I'm a bit
fed up with proxies wearing same names. Did you know that because of this,
there is a special check for stick-table name conflicts so as to reject
this one:
frontend b
bind :8888
stick-table type ip size 10
backend b
stick-table type ip size 10
I strongly doubt that by now there are still configs relying on such
special cases. I very well remember why we allow frontends and backends
with the same names, it was in hope to encourage everyone to split their
"listen" sections in two without even renaming them so that we could get
rid of "listen". In practice this did not happen, "listen" remained quite
popular for simple configs which have no business dealing with content
switching rules (typically pure TCP proxies), and we've been carrying
this thing for about two decades.
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 ?
- 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.
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
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 ;-)
