search

SUSE / caasp-salt

A collection of salt states used to provision a kubernetes cluster
Apache License 2.0
64 stars 29 forks source link

[3.0] Always wait for haproxy to be serving requests before continuing #665

Closed ereslibre closed 6 years ago

ereslibre commented 6 years ago

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.

Fixes: bsc#1109661 (cherry picked from commit 95c1980e99e0e2a9787caab02b86056db8e199c0)

Backport of https://github.com/kubic-project/salt/pull/664

flavio commented 6 years ago

Overall LGTM, I wonder if we shouldn't use some health API of HAProxy instead of trying to reach one of the API servers through the HAProxy instance.

jordimassaguerpla commented 6 years ago

@inercia : Is this still on hold?

inercia commented 6 years ago

@inercia : Is this still on hold?

@jordimassaguerpla no :-)

jordimassaguerpla commented 6 years ago

This is ready to be released. We have other fixes that are being tested right now. Once they are released, we can merge this one.