Hi Alex, On Fri, Jan 22, 2016 at 11:32:14AM +0200, Alex wrote: > Hi, > > Thank you for the answer, this is very helpful. > So to sum up my understanding, usually drain is used in operations by > setting the server in this state for a specific amount of time and then put > in maintenance state. So: > > 1. If I have an automated operation process which sets a server state to > drain, which means the server will process only current connections and new > sticky connections if any, I should not have any haproxy reload until the > state is changed to maintenance since the drain state will be lost even if > using server-state-file feature. > > 2. However, the automated operation process can use set weight 0 which > means the server will process only current connections and new sticky > connections if any (the same as point 1), then, after a specific time put > it in maintenance state and after that set weight back to 100% and state to > ready. In this case I can have a haproxy reload while "draining" with set > weight 0 if using server-state-file feature. > > Is this correct ?
Well, normally the drain state *is* saved to the file, but there is a caveat there which I don't exactly remember. Upon reload it is deduced from the fact that the weight was zero in the state file and not zero in the config I believe. There's also something else which is that the drain state cannot be set from the config and only from the CLI or agent, so we must be careful not to create a "sticky" state by which a server cannot be enabled anymore. In fact, the problem with server-state is that if we save too many information we prevent the configuration changes from being considered, and if we save too little, we lose states. So we have to compose between what is found in the state file and what appears in the config to try to guess what was changed on purpose. I remember we had a discussion with Baptiste which ended like "there may be reports for specific use cases we might have to adapt for". So in short, if the drain state is not properly saved for you, maybe we have to study how to better save it without affecting the ability to modify the config and reload (since reloads are done for config changes). Willy
