On 2025-09-08 13:59, Willy Tarreau wrote:
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.
Gotcha. Yeah, that makes it much more difficult than I thought. I dunno,
perhaps it makes sense to differ between config and dynamic. So adding
another prefix when doing stuff *not* via config to separate it from the
rest. I don't know if that would help. Just a first idea.
--
Regards,
Christian Ruppert
