HUP handling: a thought

[Alan DeKok]

Frank Cusack wrote:
> I hate the idea of requiring SQL to configure the server.  It's another
> dependency, one that is complex.  It makes inspection of the current
> config difficult, and complicates config mgmt.

  I agree.  I have issues with SQL myself.  However, the page I pointed
to is ~1k LoC, and has no external dependencies.

  Or, try this:  The server starts, reads *no* configuration, and just
listens on an SQL port for configuration.  Then, a separate program
groks the humanly-reading *conf files, and turns them into SQL nonsense
for feeding to the server.  Once that's done, the admin doesn't need to
know SQL.

  HUP could be handled by having the separate program read the new
config, and do "diff"s of the SQL statements.  It could then feed the
appropriate changes to the server.

> Now then, if the config is dynamic via SQL, how's that different than
> having it dynamic via a signal?

  Dynamic config via "edit structure X value Y to value Z" is *nothing*
like the current "kick the server in the head, and have it re-read
everything on the planet" that's done for HUP.

  Small, targeted changes are easier to manage.

>  You will have to do all the same setup,
> teardown and run all current transactions to completion while starting
> new transactions under a new configuration anyway.

  Yes.  The problem is simplified by having almost everything tied to a
REQUEST.  So anything "live" is either a thread handling a REQUEST, or a
REQUEST waiting for something.  And REQUESTs point to clients & home
servers via one pointer, which is easy to manage.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog