This is exactly what Brane's patch I referenced does. You can even do "include conf.d/*.cfg" and drop-in additional cfg files without touching haproxy.cfg.
On Tue, Jan 14, 2014 at 6:01 AM, Timh Bergström <[email protected]> wrote: > I would really love a clean/native way to basically do "includes" in > the configuration file; > > haproxy.cfg: > ## Haproxy Configuration > include "defaults.cfg" > include "statistics.cfg" > include "combined/appservers.cfg" > include "frontends/webservers.cfg" > include "frontends/mailservers.cfg" > include "backends/webservers.cfg" > include "backends/mailservers.cfg" > > haproxy -f /etc/haproxy.cfg ... > > //T > Timh Bergström > www.quickvz.com > > > > On Mon, Jan 13, 2014 at 6:30 PM, Dmitry Borodaenko > <[email protected]> wrote: >> Greetings, >> >> Can the question of loading HAProxy configuration from multiple files >> be revisited once again? >> >> The most useful implementation I've found so far is this: >> http://marc.info/?l=haproxy&m=129235503410444 >> >> Even though it's been a few years, that patch still cleanly applies to >> the latest HAProxy 1.4 and 1.5. At the time, it was rejected, and >> since then nobody has stepped up to address the concerns that were >> raised against it. >> >> As far as I understand, primary reasons this has not yet been merged >> or otherwise implemented were: >> >> 1) There's already a way to load configuration from multiple files by >> specifying multiple "-f" parameters on haproxy command line. >> >> My biggest concern with that approach is that you need an init script >> that is tailored to a specific layout of configuration fragment files, >> and may break or misbehave if its assumptions about the layout are not >> met. Multiply the number of possible layouts by the number of init >> systems (SysV init, upstart, systemd, OpenRC etc.) and making this >> reasonably generic becomes cumbersome, even before you consider >> supporting different Linux distributions. >> >> 2) HAProxy configuration is sensitive to the order of sections, and a >> fragment of a section placed at the wrong place can break all sorts of >> things. >> >> I think the best way to address this is to enforce additional >> validation on file fragments, e.g. require that any included file >> excplicitly associates each setting line with a section. In other >> words, it shouldn't have hanging setting lines that can end up being >> associated with a section from another file depending on the file sort >> order. Also, AFAIU specifying multiple configuration files on the >> command line exposes the same problem, so even merging this patch as >> is would at least not make things worse. >> >> 3) Unrestricted include directive allows to create an include loop. >> >> I believe that concern is already addressed by the patch linked above >> by setting a limit on the nesting level in the >> INCLUDE_RECURSION_LEVEL_MAX macro. >> >> Is there any other major problem I've missed? >> >> Thanks, >> >> -- >> Dmitry Borodaenko >> -- Dmitry Borodaenko
