Case in point for why puppet (and probably also chef) is perfect here. You can manage the config with puppet, and have the service "subscribe" to the config file, so that it autorestarts or reloads every time puppet changes is.
On Wed, Jan 9, 2013 at 6:14 PM, Willy Tarreau <[email protected]> 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 > > > -- zachary alex stern I systems architect o: 212.363.1654 x106 | f: 212.202.6488 | [email protected] 60-62 e. 11th street, 4th floor | new york, ny | 10003 www.enternewmedia.com
