Hi Tristan, On Fri, Aug 09, 2024 at 03:51:24PM +0000, Tristan wrote: > Hi Willy, > > > On 9 Aug 2024, at 16:26, Willy Tarreau <w...@1wt.eu> wrote: > > [...] > > 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 ? > > If I'd realized, I'd have assumed I found a bug I think; wonder how that even > gets handled by things like the prom exporter which key purely by name? > > +1 for drop in 3.1 > > > - for backends + frontends, deprecate same names in 3.1, drop in 3.3, > > or drop now ? Or keep them ? > > For a pure proxy case without any load balancing (1 fe, 1 be, 1 server) I can > see it being a bit heavy to have to name both, likely xyz-frontend and > xyz-backend or something. Is that justification enough? I'm not convinced.
That was the initial reason for that. But how many configs are using a frontend and a backend with similar names ? Mystery. Even the stats are confusing in such a case. > Neutral. > > wrt the stick tables example, the real crime is that naming them explicitly > isn't mandatory, at both declaration and usage time... I'm not sure what the > scope rules are for them, but I promptly decided it was not desirable > knowledge when I started using them... I contemplated the possibility of adding an optional "name" argument to the "stick-table" directive a while ago. And I figured that it would make it almost mandatory to totally decorellate the tables from the proxies. These have already been split in the past since it's possible to declare them in peers section, but that causes a configuration issue: if you merge config fragments from various customers and they're allowed to name their table as another customer's proxy, it becomes a bit annoying. It also means having a same namespace for tables and backends, which reproduces the issue we currently have with fronts and backs. Nothing unsolvable, of course, but it definitely needs some thinking before doing a mistake. BTW, for peers, the table's name contains the peers section name prepended to it, e.g. "mypeers/t1". That might be something to do with fronts/backs as well after all, which may also finally permit to support multiple tables per proxy and avoid those scary configs with hundreds of empty backends that just carry one stick-table each. > > [...] 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. > > +1 Thanks for sharing your views on this! Willy
