On Fri, Jun 19, 2026 at 11:12:54AM +0000, Stephan, Alexander wrote: > Hi, > Thanks for the second pass! > ▎ The PR_O3_SRV_RENAME approach seems good. > Good to hear. > ▎ Regarding the stick-table checks: these are not present in del server, > ▎ so either del server has a bug, or these checks are unnecessary here. > You are right. I removed the stick-table/peer-sync checks to stay consistent > with del server. > ▎ srv_validate_name(): add server already goes through _srv_parse_init() > ▎ which calls invalid_char(), so the call in cli_parse_add_server() is > ▎ redundant. And for rename, invalid_char() should be sufficient. > Agreed. I removed srv_validate_name() entirely. The rename path now uses > invalid_char() for the character-set check (which covers > [A-Za-z0-9_:.-], including : for IP:port names) plus an explicit length > check against the event data name field and an empty-string check for > a cleaner error message. The redundant call in cli_parse_add_server() is also > gone. > ▎ Formatting: checkpatch will complain but that is not an issue. > Alright, good to know, thanks. > Then, I am looking forward to your feedback after the internal discussion on > the resolver/SRV_F_NON_PURGEABLE question.
Hi Alexander, I'm back after a discussion about this feature with Willy. We are both interested to see this feature merged. However there is still final remarks before this can be done. First, Willy has pointed to me that the backend option to allow renaming is probably unnecessary. It can be frustrating for users to discover at runtime that a server can't be renamed as the config option is missing. Also, add and delete server operation are not conditionned by an extra option, so it's better to keep a similar approach here. Regarding the discussion about how to determine if a server can or cannot be renamed, here are our proposition. First, you should provide a new patch which introduces a new server flag, used for servers who are referenced in the configuration by their name. This SRV_F_NAME_REFD (I let you propose a better naming if you want) should replace SRV_F_NON_PURGEABLE in most places, except for the resolvers case. In the same patch, delete server handler must be adjusted to now test the flag combination SRV_F_NAME_REFD + SRV_F_NON_PURGEABLE. Then, in the patch dedicated to the rename server handler, you just have to check for SRV_F_NAME_REFD. This guarantees that rename operation will only be blocked due to a name reference. This is the better approach for future evolutions. Hum I had a new look at the current code and I see that the server ID pointer can be directly referenced when using srv_name sample fetch. I'm not sure thus that the rename operation is totally safe. Maybe Willy or others whill have some ideas about this ? Regards, -- Amaury Denoyelle
