MINOR: server: explicitly commit state change in srv_update_status()
As shown in 8f29829 ("BUG/MEDIUM: checks: a down server going to
maint remains definitely stucked on down state."), state changes
that don't result in explicit lb state change, require us to perform
an explicit server state commit to make sure the next state is
applied before returning from the function.
This is the case for server state changes that don't trigger lb logic
and only perform some logging.
This is quite error prone, we could easily forget a state change
combination that could result in next_state, next_admin or next_eweight
not being applied. (cur_state, cur_admin and cur_eweight would be left
with unexpected values)
To fix this, we explicitly call srv_lb_commit_status() at the end
of srv_update_status() to enforce the new values, even if they were
already applied. (when a state changes requires lb state update
an implicit commit is already performed)
Applying the state change multiple times is safe (since the next value
always points to the current value).
Backport notes:
2.2:
Replace
struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state)
by
struct task *srv_cleanup_toremove_connections(struct task *task, void *context, unsigned short state)
(cherry picked from commit 22151c70bbc8af166ccbe04f50950f80d4a22c7d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit fad52151fd235a08d85c307344968b7a847fce4a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit c48e9f3dcd14ac3e037f760fa203d2d8e6dab8b6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
1 file changed