couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: server configuration stuff
Date Thu, 10 Apr 2008 21:25:02 GMT
On Apr 10, 2008, at 22:02, Damien Katz wrote:
> Currently that CouchDB handles configuration stuff is to reads in  
> it's configuration setting at startup time the couch.ini file, and  
> then feeds those settings as startup arguments to the various child  
> servers processes. This requires that to change a setting you must  
> restart to take effect.
> This is fine for now, but we can do better. I'd like to enhance this  
> by providing a configuration module that allows for configuration  
> settings to be changed at runtime, and automatically have those  
> changes take effect without requiring a server restart.

I generally agree, that we can do better and I am very much in favour  
of runtime configuration changes. I still need to make up my mind on  
how to do that.

> The way I was thinking it would work, at startup the server  
> configuration module sucks up the settings from the couch.ini, then  
> the child processes are started normally, but without startup  
> arguments. The child processes then query the runtime module at  
> startup, or whenever, to get their configuration data.

The first question I guess is, if we want to continue to use couch.ini  
(or some other configuration file) or if we want to, for example,  
start storing the configuration inside a couchdb document. The  
document would make it easy (easier?) to integrate configuration into  
Futon, our admin client and other software that wants to configure  

A configuration file still feels more robust, though. In case a  
configuration setting would prevent the server from starting, you  
would actually be able to change that setting (Maybe that is just me  
coming from a background with less robust software). Or there are  
settings that need to be known before CouchDB can launch.

> It should be possible for the core modules to subscribe  
> notifications of configuration updates. In Erlang, this is typically  
> done by the modules registering a callback function. So when a  
> configuration setting is updated, it would get invoked with the  
> changed settings as arguments.

That sounds about right.

> And when a configuration setting is changed at runtime, the module  
> should write the new setting back to the couch.ini file. And it  
> should be able to handle updates to settings, etc, and ideally still  
> preserve all previous formatting and comments.

I'm not very comfortable with changing the config file  
programmatically. In that case I'd want to be able to validate its  
structure after a change to make sure nothing broke (and I am not  
suggesting XML here). On the other hand, if we can make that reliable,  
I might feel better.

> So, some questions. What do people think of this in general? Or  
> should we be using the apache conf format instead of ini? Maybe we  
> should use json?

The use of JSON sounds nice as it removes a possibly tedious and error  
prone parsing and generating step for the config module and I think  
JSON is enough of a plaintext format to qualify for a configuration  
file. People dealing with CouchDB would need to know JSON anyway and  
for those who don't it is easy enough to read.

> One things I'd like to see is that configuration stuff be editable  
> in a text editor. However, I might be dissuaded to start using a  
> CouchDB database to store everything but the most critical startup  
> information.

Like I said above, this would be okay if we can guarantee that CouchDB  
would launch always to the point that we can reconfigure the config  
database in case of problems.


View raw message