Hey,
I don't understand the necessity of the hold valid config option. DNS
has something that takes care of this for you called the TTL. Besides if
hold valid is shorter then the TTL it would be kind of pointless since
the resolvers you are querying won't re-resolve until the TTL expires.
Tbh I don't really see the point of configuring the resolvers in haproxy
when the OS has perfectly fine working facilities for this? What is the
benefit besides possibly causing lookups to happen twice, once from the
OS resolving stack and once from haproxies? If you really want exactly
the same behavior as described you could always configure a local
resolver that queries multiple other resolvers instead of recursing itself.
-Robin-
Marco Corte wrote on 7/15/2015 08:28:
Il 14/07/2015 22:11, Baptiste ha scritto:
- when parsing the configuration, HAProxy uses libc functions and
resolvers provided by the operating system => if the server can't be
resolved at this step, then HAProxy can't start
[...]
> First, we want to fix the error when HAProxy fails starting up because
> the resolvers pointed by the system can't resolve a server's IP
> address (but HAProxy resolvers could).
> The idea here would to create a new flag on the server to tell HAProxy
> which IP to use. The server would be enabled when the IP has been
> provided by the expected tool.
Hi, Baptiste.
Since I am used to IP address I cannot figure out all possible
implication of the server name DNS resolution :-)
IMHO HAproxy should start in any case if the configuration is valid;
only the unresolvable items should be marked as disabled or failing or
down or whatever.
A wrong DNS entry could stop a otherwise perfectly working configuration.
Why not providing an option to start haproxy even if not all servers
can be resolved?
Your proposal of the "init-addr" could be useful for a trick: I can
set a surely unreacheable address to let haproxy start and then
force/wait for the name resolution to have a working server.
A "NX" server state would be very nice.
.marcoc
