On Fri, Jan 22, 2016 at 10:46 AM, Willy Tarreau <w...@1wt.eu> wrote:
> 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
>
Hey,
I commented this case in the code:
/* apply drain mode if server is currently enabled */
if (!(srv->admin & SRV_ADMF_FMAINT) && (srv_admin_state & SRV_ADMF_FDRAIN)) {
/* The SRV_ADMF_FDRAIN flag is inherited when srv->iweight is 0
* (srv->iweight is the weight set up in configuration)
* so we don't want to apply it when srv_iweight is 0 and
* srv->iweight is greater than 0. Purpose is to give the
* chance to the admin to re-enable this server from configuration
* file by setting a new weight > 0.
*/
if ((srv_iweight == 0) && (srv->iweight > 0)) {
srv_adm_set_drain(srv);
}
}
srv_iweight, taken from the state file, must be 0 and iweight provided
by the configuration must be greater than 0 to apply the FDRAIN mode.
So I would say yes, we may not be applying the DRAIN state set up by
the 'set server state drain' command.
I have to dig into that one.
Baptiste
