On Fri, Apr 6, 2018 at 4:54 PM, Willy Tarreau <[email protected]> wrote: > On Fri, Apr 06, 2018 at 04:50:54PM +0200, Lukas Tribus wrote: > > > Well, sometimes when you're debugging a configuration, it's nice to be > > > able to disable some elements. Same for those manipulating/building > > > configs by assembling elements and iteratively pass them through > > > "haproxy -c". That's exactly the reason why we relaxed a few checks in > > > the past, like accepting a frontend with no bind line or accepting a > > > backend with a "cookie" directive with no cookie on server lines. In > > > fact we could simply emit a warning when a resolvers section has no > > > resolver nor resolv.conf enabled, but at least accept to start. > > > > Understood; however in this specific case I would argue one would > > remove the "resolver" directive from the server-line(s), instead of > > dropping the nameservers from the global nameserver declaration. > > No, because in order to do this, you also have to remove all references > on all "server" lines, which is quite a pain, and error-prone when you > want to reactivate them. > > > Maybe a config warning would be a compromise for this case? > > Yes, that's what I mentionned above, I'm all in favor of this given that > we can't objectively find a valid use case for an empty resolvers section > in production. > > Cheers, > Willy >
Ok, so just to summarize: - we should enable parsing of resolv.conf with a configuration statement in the resolvers section - only nameserver directives from resolv.conf will be parsed for now - parsing of resolv.conf can be used in conjunction with nameserver directives in the resolvers section - HAProxy should emit a warning message when parsing a configuration which has no resolv.conf neither nameserver directives enabled Is that correct? Baptiste
