incubator-couchdb-dev mailing list archives

Heya,
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
CouchDB.
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.
Cheers
Jan
--