[PEAK] runIni => ZConfig revisited

[John Landahl]

On Fri, 14 Nov 2003 13:30:56 -0500, Phillip J. Eby <pje at telecommunity.com> 
wrote:

> At 07:52 PM 11/14/03 +0200, alexander smishlajev wrote:
>> one of the biggest problems for us now is the requirement to restart 
>> the application upon any change in configuration file.  we have a 
>> strong need to reload config files on the fly, restarting or updating 
>> only those components that have their configuration changed.
>
> Perhaps you could create a top-level component that holds the entire 
> configured subtree, and simply discards/reloads it when necessary.
>
> (I'm assuming here that the issue with restarting is that Python startup 
> and module importing is too slow, not that recreating the app's 
> component tree is a problem.)

This is a problem for us, too.  It's not that speed is necessarily an 
issue, it's that the application is a long running process with various 
components doing independent work on varying schedules.  It would be 
disruptive if the entire application had to restart just to change a 
single configuration item for one of the components.

Ideally the application would have a) one component periodically 
downloading configuration updates from a central server, b) 
publish/subscribe on configuration keys.  Components could then subscribe 
to the configuration keys they care about, receive notifications when 
changes are made, and do whatever is necessary with the information, such 
as resetting their work schedule, changing the location of the server they 
talk to, change the template of an external command they run, etc.

This would allow configuration to be stored and updated centrally, with 
agents adapting as new configuration information is sent their way, 
without the need to transmit a new configuration file and restart the 
agent.  So that's two main reasons: we don't want to have to transmit a 
new configuration file to potentially thousands of hosts, and we don't 
want to have to restart the agent once it gets there, potentially 
disrupting work in progress.

_jpl_