Hi Willy,
I believe in previous versions of haproxy having an unresolvable host
name at start up did not cause haproxy to error out. Bellow is the
change log I found:
2010/03/30 : 1.3.24
- [BUG] config: report unresolvable host names as errors
I wrongly assumed that haproxy performed DNS lookups after startup.
After reading the past few emails I'm assuming that haproxy, on
startup, performs a lookup for backends' hostnames, gets an IP
address, and stores this IP for later use. If there is no IP, haproxy
errors out, and haproxy does not perform DNS lookups other than at
startup.
It completely makes sense for static configurations, but it does limit
haproxy in its application.
I think an option for the backend works perfectly because, as you
said, most people statically define their farms. Static is easier and
less complicated, but limited. Everything has it's pros and cons.
Cheers!
Andres
On Sat, May 12, 2012 at 4:27 AM, Willy Tarreau <[email protected]> wrote:
> On Sat, May 12, 2012 at 11:09:22AM +0200, Baptiste wrote:
>> > Well, I must say I'm unsure what we'll do upon startup, because if we
>> > accept to start with buggy host names, a number of admins will get
>> > trapped with errors in their configs causing servers to remain down
>> > forever. At least right now they know from the beginning that they
>> > have to fix their configs. Maybe we'll have to support a per-backend
>> > option to enable delayed host name resolution, I don't know yet.
>> >
>> > Regards,
>> > Willy
>> >
>>
>> I think that you should allow this kind of behavior for people using
>> Amazon (or any cloud) or people, like Andreas, who uses DHCP+
>> automatic DNS update.
>> So untill the server has startup, it does not know its own IP address
>> and of course, the DNS resolver can't point to it.
>
> I understand this problem, but I mean that I don't want to make all other
> users (say 99.99% of users) suffer from a lack of control of configuration
> errors just because of a few ugly uses (because having a server dynamically
> addressed is ugly, no matter whatever good excuse you have for this).
>
> So I think it will be an option in the backend so that serious users doesn't
> suffer from this.
>
> Cheers,
> Willy
>
