On Mon, Sep 08, 2025 at 01:44:59PM +0200, Christian Ruppert wrote:
> On 2025-09-08 12:01, Willy Tarreau wrote:
> > I tend to think that we would probably need to have a directive to
> > explicitly request automatic naming based on a few criteria that will
> > differ between deployments.
> >
> > Ideally if we could figure how to relax this before 3.3 it would be
> > nice IMHO.
>
> Yeah, that'd be really nice indeed.
> I was just thinking about using existing uniqueness mechanisms. So that's
> why I thought using the proxy name + the type a prefix and additionally the
> servername for servers would be sufficient.
> All those already need to be unique and would throw an alert.
The problem is not uniqueness *within* a config but uniqueness *across*
configs. E.g. you have a backend with 10 servers. The load becomes high,
you add a 11th server. It decreases, you go down to 9, then you're back
to 10 after a small bump. With automatic numbering mechanisms (like
server-templates but not only), you'd have srv1-10, then 1-11, then 1-9
then 1-10 again. But nothing indicates that the last srv10 has any relation
with the first one, and it's in fact very possible that when the load
decreased, when going from 11 to 9 servers, you killed 4 and 5 because
they had no connection, and that after a reload all the subsequent ones
got renumbered. In this case all your stats are completely mangled.
That's why initially we said "ok we've been wrong on this, users name
their servers different nowadays and it's no longer the haproxy config
that defines everything, let's let users name their servers themselves
using a guid". Running in a cloud environment you'd typically assign the
instance ID there for example.
> But I wouldn't
> mind also adding IP+Port as well or even more, if necessary, like PID or
> something.
PID would not work because all servers' stats would be replaced on reload.
> Is there any other use for GUIDs other than HAProxy internal?
It's only used to reliably designate and distinguish servers. Now with
this we do provide the guarantee that if two guids are equal, it's the
same server, and if they're different, it's a different one.
But don't get me wrong, I'm not a VM user myself and I like to know
where my stuff is running, so I, too, would like to use stable automatic
identifiers for servers that have no reason to change. That's why I tend
to think that such options could make sense:
- manual guid (the default): what we have now
- automatic guid based on ID (position in the config) : what's being
used for stats etc. I doubt it has any use anymore unless 'id' is
forced, given that just commenting a server will change all subsequent
ones. However for those already forcing IDs this could simplify the
naming.
- automatic guid based on address+port : works fine in environments
where servers appear and go all the time but addresses are stable
(dynamically allocated VMs). Will not work when addresses are not
known at boot (dynamic DNS-based discovery) nor when duplicates
exist within the same farm.
- automatic guid based on name : works fine where configs are managed
by humans who already assign the real server's asset name as its name.
Will not work with server-templates.
There may be other options that just don't come to my mind.
Willy
