Willy, Thanks for your thoughts. I see that you have thought about these issues much more than I have. I just wanted to get you some feedback from a potential haproxy user.
As for your point that I would need to edit the static configuration file incase of a complete restart of HAProxy, I would point out that if the backend servers are responsible for their HAProxy configuration, then the static configuration file only needs to configure the minimal set of backend servers. When HAProxy restarts, it would send the configuration data to the statically defined backends and those servers would be responsible for dynamically reconfiguring HAProxy back to its desired settings. This could also include adding any additional servers. I guess my feedback to you would be that I would rather see my backend servers define how HAProxy sees them through some sort of dynamic configuration interface. I can see how I could implement this by using other scripts/tools to dynamically rewrite the config file and reload HAProxy. This is what I'll do if you don't choose to implement more support for dynamic configuration from the backend. On Jan 9, 2013, at 6:14 PM, Willy Tarreau <w...@1wt.eu> wrote: > Hi Kevin, > > On Wed, Jan 09, 2013 at 04:13:28PM -0500, Kevin Heatwole wrote: > (...) >> 1. Setting new interval time for subsequent configuration checks to the >> server. >> 2. Setting new maxconn or weight for the server (allowing backend to >> "throttle" or "increase" load for itself). >> 3. Setting server state (DOWN, MAINTENANCE, UP, STARTING, STOPPING, >> DAMAGED) changing how HAProxy treats existing connections or new connections >> for the server. >> 4. Change server from active to backup (or vice versa). >> 4. Adding new server to backend by having configuration check return new >> server configuration. >> 5. Changing any other useful settings that affect backend servers. > > This is more or less what was spec'd by Malcolm recently and implemented > by Simon. We found that some details could be adapted before merging, but > in general it's very close. > > Anyway you won't hot-add a server that soon : lots of internal sizes > (including file descriptor limits) depend on the number of servers. At > most we'd have provisions for adding up to N extra servers. Also, a lot > of checks are currently performed on server configuration (eg: don't > track a server that tracks yourself). Doing some of these checks at > runtime and providing enough feedback to the user to react will be quite > tricky. > > In practice, you can already tweak a number of things on the stats CLI. > I'd like to be able to switch a server's state betwen active/backup, but > it's already algorithmically complex. Changing an address would be really > nice, but comes with issues again. > > Anyway, whatever changes you make, you'll have to do them on the config > file too because if you restart your process, you don't want all these > changes to be lost ! So right now changing the config only and doing a > reload is already a reasonable tradeoff. > > Willy > >
