You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 13, 2018. It is now read-only.
Sometimes, when scaling a service, HAProxy gets restarted with a new configuration but the docker dns seems not ready it to resolve the container name.
This makes HAProxy to fail starting properly.
I added : EXTRA_DEFAULT_SETTINGS: "default-server init-addr last\\,libc\\,none"
So that even if the backend hostname does not resolve, it would resolve to none and start anyway.
But then HAProxy keeps that backend in a "MAINTanance" status, and it won't come up after by itself, unless HAProxy is restarted. I'll create an issue for this to be fixed in HAProxy as well.
I suggest you setup the "default-server init-addr" with the none fallback ("last,libc,none") per default in the dockercloud-haproxy image.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Sometimes, when scaling a service, HAProxy gets restarted with a new configuration but the docker dns seems not ready it to resolve the container name.
This makes HAProxy to fail starting properly.
I added :
EXTRA_DEFAULT_SETTINGS: "default-server init-addr last\\,libc\\,none"
So that even if the backend hostname does not resolve, it would resolve to none and start anyway.
But then HAProxy keeps that backend in a "MAINTanance" status, and it won't come up after by itself, unless HAProxy is restarted. I'll create an issue for this to be fixed in HAProxy as well.
I suggest you setup the "default-server init-addr" with the none fallback ("last,libc,none") per default in the dockercloud-haproxy image.
The text was updated successfully, but these errors were encountered: