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 >
