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
--
