Hi Christian, On Mon, Sep 08, 2025 at 11:32:22AM +0200, Christian Ruppert wrote: > Hi list, > > so with the new shm-stats-file option in 3.3, setting GUID's is a > requirement. Wouldn't it be easier to still allow setting GUIDs by hand but, > as default, generate some implicit/automatic. > IMO it would be fine to just auto-prefix the GUID's with either > frontend/backend/listen and then the actual proxy name. So that a GUID for > "frontend foobar" would be "frontend-foobar" for example.
We've thought about it already, but *for now* refrained from doing so in order to avoid reproducing the mess of the "id" field. Indeed, the main problem that has been caused for stats correlation between reloads was that server with id XXX from process 1 was not necessarily the same as the server with that id in process 2. We've added guid to let the provisioning tools set the IDs themselves based on something stable (i.e. and object from the database). > frontend/backend/listen proxy names need to be unique already. So we > basically already have a good base for unique IDs. > > The same could be done with servers, though a bit different. type + proxy > name + servername. The problem is that the server name is very often just a generated sequence number like "srv123". We've seen such problems a lot with the stats files where neither names nor positions were sufficient. > That would save a lot of config directives etc., esp. for huge configs. We do understand this and that's also why we're trying to find a middle ground solution. But really, the trap of automatic naming/numberring based on the position is super dangerous. At least I'd rather favor backend name +IP+port in this case, but there remains the issue of duplicates and dynamically addressed servers. > Also > much easier if you don't need any special sort of GUID's for whatever > reason. If you need the GUID for something, it's also pretty much straight > forward to guess it. If someone still needs it, it would simply override the > implicit default. I agree with the ease of use, but IDs were also trivial to use yet they have been causing all the problems we know to the point of nobody using them anymore (even the last regression we discussed was caused by an attempt at finding an alternative to them). At the same time I do understand the value of automatic naming for complex configs that are managed by humans, because in these ones we know that the ambiguity does not exist. 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. Thanks, Willy
