On Wed, Jun 15, 2011 at 11:21:57PM +0200, Mike Hoffs wrote:
> Maybe it is possible to add an include conf.d in the main config, and after
> that part all other config files will be automaticly included. Something like
> apache can do ?
As I explained in another thread, includes are really nasty for configs
which can have different meaning depending on the context.
For instance, imagine how you would proceed with such a config :
listen public
bind :80
balance roundrobin
default-server check inter 10
server sorry 10.10.10.10:80 backup
include app01.conf
option httpchk /
with app01.conf containing that :
server srv1 1.1.1.1:80 cookie A
server srv2 1.1.1.2:80 cookie B
server srv3 1.1.1.3:80 cookie C
server srv4 1.1.1.4:80 cookie D
First, you'll notice that when reading the included file alone,
you have no idea about how the cookie's used, nor if the servers
are checked, or how they are checked. It's already a mess. Now
let's add a bit more of a mess. You're on holidays and someone
decides to add a section to app01.conf :
server srv1 1.1.1.1:80 cookie A
server srv2 1.1.1.2:80 cookie B
server srv3 1.1.1.3:80 cookie C
server srv4 1.1.1.4:80 cookie D
defaults app01_settings
cookie JSESSIONID prefix
Then this "defaults" section will in fact silently change the "defaults"
semantics for all sections declared after the first one in the main file.
It will disable "option httpchk /" for the first section, and enable it
for all subsequent sections, as well as fixing the cookie name in prefix
mode.
Believe me I started with the include method in mind, but I finally stopped
because there were too many caveats. It basically is impossible to track the
effect of any declaration on other sections, and the config quickly becomes
a nightmare to debug.
Another issue was loop detection, though it can in general be covered by
non-trivial algorithms which involve the file name and inode. Last, there
are other caveats when using subdirectories, because while using paths
relative to the file holding the "include" directive looks like the most
intuitive approach for the user, it's also the one causing the most
headaches when troubleshooting, and for loop detection.
I really think that the multiple file solution is a good compromise. We
might implement something such as loading all files from a directory,
that could make sense, but quite frankly, given that many people more
or less generate their files, the features only saves a simple command
such as "cat $dir/*.conf | haproxy -f /dev/stdin" operation in a startup
script, which is far from being the most complex issue to solve !
Regards,
Willy
