I agree. On Mon, Apr 9, 2018 at 1:35 AM, Baptiste <bed...@gmail.com> wrote:
> > > On Fri, Apr 6, 2018 at 4:54 PM, Willy Tarreau <w...@1wt.eu> 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 >
