We could do the wait on the different places to avoid a generic piece
like haproxy having to wait for a specific component like the apiserver,
but we are already writing specific components in its configuration, and
a future reordering of states could trigger this error again.
So, when we kill haproxy, wait for it to be serving requests again before
continuing with the next state.
On the 2 to 3 upgrade this was causing a failure because right after
restarting haproxy we were trying to drain the node. Since we run this
operation on the very same machine that is being targeted, this kubectl
command cannot reach the apiserver (because haproxy is still initializing),
causing the whole update orchestration to fail.
We could do the wait on the different places to avoid a generic piece like haproxy having to wait for a specific component like the apiserver, but we are already writing specific components in its configuration, and a future reordering of states could trigger this error again.
So, when we kill haproxy, wait for it to be serving requests again before continuing with the next state.
On the 2 to 3 upgrade this was causing a failure because right after restarting haproxy we were trying to drain the node. Since we run this operation on the very same machine that is being targeted, this
kubectlcommand cannot reach the apiserver (because haproxy is still initializing), causing the whole update orchestration to fail.Fixes: bsc#1109661