Hi Cyril, Baptiste,
Just a quick response on this part to clear up some confusion.
On Mon, Jul 20, 2015 at 01:11:22AM +0200, Cyril Bonté wrote:
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
Hi Baptiste,
late feedback but it's better than none ;-)
Le 12/07/2015 23:38, Baptiste a écrit :
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).
It is pretty awaited
On 07/17/2015 10:37 PM, Baptiste wrote:
First would be resolution of SRV records and actually using the port
supplied by the SRV record as the port for the server. I looked at the code
and it doesn't seem like too much work, most of it would probably be
changing the config stuff accordingly.
Hello,
On 07/14/2015 10:11 PM, Baptiste wrote:
snip
I know the message above is very long, but we really need your feedback!
/snip
First, many thanks for tackling this! It surely makes many peoples live
much easier. Reading this makes me want two things, one of them being a
little
On Wed, Jul 15, 2015 at 8:28 AM, Marco Corte ma...@marcocorte.it wrote:
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
Hi Robin,
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
Actually a local resolver can take care of that for you as well since every
resolver I know allows configuring a different destination on domain basis.
Also as described in the first email, the server has to be resolvable via
the OS resolving stack as well otherwise haproxy won't start.
First would be resolution of SRV records and actually using the port
supplied by the SRV record as the port for the server. I looked at the code
and it doesn't seem like too much work, most of it would probably be
changing the config stuff accordingly.
You're right, this could be an
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.
Hello Robin,
On 07/15/2015 08:49 AM, Robin Geuze wrote:
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
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
Hey Nenad,
Actually a local resolver can take care of that for you as well since
every resolver I know allows configuring a different destination on
domain basis. Also as described in the first email, the server has to be
resolvable via the OS resolving stack as well otherwise haproxy won't
On Sun, Jul 12, 2015 at 11:38 PM, Baptiste bed...@gmail.com wrote:
hi all,
As you may have noticed already, HAProxy 1.6-dev2 version has
integrated a new feature: server IP address resolution using DNS.
Main purpose of this dev is to make HAProxy aware of a server IP
change when using
13 matches
Mail list logo
