Hi Willy, > > Seems that it's considered an expected behavior to consider > > optimistically the server as UP > > when leaving MAINT mode, even if the L4 health checks are not completed > > yet.
> Normally using the existing API you could forcefully > mark the server's check as down using this before leaving maintenance: > set server <backend>/<server> health [ up | stopping | down ] > Doesn't it work to force it to down before leaving maintenance and wait > for it to succeed its checks ? That would give this to leave maintenance: > set server blah health down; set server blah state ready > By the way that reminds me that a long time ago we envisioned a server > option such as "init-state down" but with the ability to add servers on > the fly via the CLI it seemed a bit moot precisely because you should be > able to do the above. But again, do not hesitate to tell me if I'm wrong > somewhere, my goal is not to reject any change but to make sure we're not > trying to do something that's already possible (and possibly not obvious, > I concede). I just did some tests to share with you: 1) - Forcing health "DOWN" before exiting "MAINT" mode - COMMANDS: set server test_backend/s1 state maint set server test_backend/s1 health down set server test_backend/s1 state ready LOG: Server test_backend/s1 is going DOWN for maintenance. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Server test_backend/s1 is UP/READY (leaving forced maintenance). In this case, forcing health as "DOWN" when in MAINT mode isn't evaluated by haproxy, and it optimistically comes back to "UP" once state is set to READY. 2) - Entering "MAINT" mode when health is "DOWN": COMMANDS: set server test_backend/s1 health down set server test_backend/s1 state maint set server test_backend/s1 state ready LOG: Server test_backend/s1 is DOWN, changed from CLI. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Server test_backend/s1 was DOWN and now enters maintenance. Server test_backend/s1 is UP/READY (leaving forced maintenance). In this case, health is successfully forced to "DOWN" before entering MAINT mode, but it's again optimistically restored as "UP" once state is set to READY. 3) - Exiting "MAINT" mode passing through "DRAIN", forcing health "DOWN" - COMMANDS: set server test_backend/s1 state maint set server test_backend/s1 state drain set server test_backend/s1 health down set server test_backend/s1 state ready LOG: Server test_backend/s1 is going DOWN for maintenance. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Server test_backend/s1 is UP/DRAIN (leaving forced maintenance). Server test_backend/s1 remains in forced drain mode. Server test_backend/s1 is DOWN, changed from CLI. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Server test_backend/s1 remains in forced drain mode. Server test_backend/s1 is DOWN (leaving forced drain). That one is working as intended, since it's exiting from MAINT with health "DOWN", and then haproxy evaluates the health before going "UP". ... but it's passing through "DRAIN", and I don't know it's intended. Do you think something has to be different on the first two tests I did? Maybe forced health "DOWN" should have been honored once out from "MAINT" to "READY" state? Thanks, Matteo
