couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Yokomizo" <>
Subject Re: server configuration stuff
Date Thu, 10 Apr 2008 20:22:15 GMT
On Thu, Apr 10, 2008 at 5:02 PM, 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.
>  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.
>  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.
>  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.
>  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?
>  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.
>  Thoughts please.

A couple of thoughts.

1. Why not use the usual Erlang approach for code update, using the
loop for receiving messages and handling config updates, it seems
cleaner and a better fit. This way you need only a single process to
handle the config file format and notify the rest.

2. Also it would be simpler to have almost every config inside a
CouchDB database, so you startup using the default config and the
config process reads the database for the real config info and
notifies the other modules of the actual values. With this in place
it'll be easier to have other config formats in the future: just make
some module that understands format foo and writes/reads it to/from
couchdb. The config process will see the changes and propagate them.

IME it's better to keep config files away from the core of some
application and let some external agent interpret the files and
configure the application using an api.

Best regards,
Daniel Yokomizo.

View raw message