On Sun, Jan 24, 2016 at 9:01 PM, Baptiste <[email protected]> wrote:
> On Fri, Jan 22, 2016 at 10:46 AM, Willy Tarreau <[email protected]> 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
Hi,
In the code below, srv_adm_set_drain is never executed when its state
from previous process is FDRAIN.
/* 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);
}
}
I think there is an error in the comment: "The SRV_ADMF_FDRAIN flag is
inherited when srv->iweight is 0" is wrong.
When server's weight is set to 0 in the conf, then drain flag is not set.
As Willy stated in a previous email, we wanted to avoid some corner cases.
As far as I remember, it was related to the fact that we could not
cancel the DRAIN state from the cfg file if it is set into the state
file. It must be disabled through the
Baptiste
