Hello, Le mar. 17 déc. 2019 à 11:11, Willy Tarreau <w...@1wt.eu> a écrit :
> Hi Olivier, > > On Tue, Dec 17, 2019 at 09:20:21AM +0100, Olivier D wrote: > > That's not what I was saying. I'm already using "show server state", and > > that's exactly what leads me to hours of debugging : between two versions > > of my haproxy config file, I changed backend server port from 80 to 443. > > When HAProxy reloaded, it loaded server state file and loaded both the > > previous state(up/down) of the server, but also the server port. That's > why > > HAProxy never used port 443 as backend port and was still using old port > 80. > > This is not clearly stated in the configuration (or maybe I missed it ?), > > that's why I was asking whether it is an expected behaviour. In my mind, > > the server state was only used to get server status between two reload, > not > > more informations. > > Bah, state-file strikes again :-( > > We predicted exactly this when it was designed. Some people complain that > their changes are lost and others that their changes are kept. We discussed > this already with Baptiste and we figured that the only solution to this is > to change the format to include, for each and every field, *both* the > config > config state and the current state, so that upon reload, the state file > parser can detect what changed from previous running instance: if the > config > changed, you want the config change to be taken into account. If the config > didn't change, then very likely you want to keep the previous state. > > It's a really tricky thing because most of the time a reload is made in > order to apply a change, but this change may conflict with what is in the > state file in a way that's not that determinist :-/ Personally I don't like > the idea of having two authoritative sources for a single configuration, > which is why we must make this state file processing stricter and its > contents more detailed. > > It's worth noting that some people are already abusing it by writing > their changes directly to the state file and avoid touching the config > (typically just have a server-template directive in the config and all > the details in the state file). This shows how tricky the situation can > become every time we try to address one's needs and break someonee else's > :-/ > > Willy > Ah! thank you for the explanation ! Just explaining this in doc should be enough. I always thought that only the state (UP/DOWN/MAINT) was loaded from that file. What would you think of the following modification ? server-state-file <file> <state-only?> Specifies the path to the file containing state of servers. [...] Please note that when we say "state of servers", it means not only server status (up/down/maint) but also IP/port. [...] if "state-only" is present, then only server state (up/down/maint) will be reloaded. IP/port will be filled with what is provided in config file. Well, like this it's quite ugly but you see my point :) It's backward-compatible, and you can enforce the behaviour you expect. Olivier
