Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 11 Apr 2008 11:54:47 +0100
From: Noah Slater <nslater@apache.org>
To: couchdb-user@incubator.apache.org
Cc: couchdb-dev@incubator.apache.org
Subject: Re: server configuration stuff
Message-ID: <20080411105447.GA21676@bytesexual.org>
Mail-Followup-To: couchdb-user@incubator.apache.org,
	couchdb-dev@incubator.apache.org
References: <2C5BFE50-C6FA-4A08-BEF6-EA8658A183BC@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2C5BFE50-C6FA-4A08-BEF6-EA8658A183BC@gmail.com>
Organization: The Apache Software Foundation <http://www.apache.org/>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Thu, Apr 10, 2008 at 04:02:18PM -0400, Damien Katz wrote:
> 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.

This sounds like a good idea.

The usual way to do this would be to send a SIGHUP to the daemon telling it to
re-read in it's configuration files. As discussed on IRC, I do not think any
automatic reloads of configuration is wise because:

 * the configuration may sit on a network/unstable filesystem which could
   produce read errors that could confuse or kill CouchDB
 * the configuration could not be edited by a administrator while CouchDB was
   running as the server would reload after every save to the file
 * automatic packaging systems may overwrite configuration files before the
   administrator has time to revert them (happened to me a few times)

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

Are you suggesting a Web based configuration editor in Futon or similar?

Sounds like a pretty nice idea to me.

Writing out to INI files seems simple enough and I know of at least one Python
library that is designed to handle exactly this situation:

  http://www.voidspace.org.uk/python/configobj.html

INI files also have the benefit (over say Apache httpd style) of being a
de facto standard, which will help us exploit any 3rd party tools.

On Thu, Apr 10, 2008 at 11:25:02PM +0200, Jan Lehnardt wrote:
> 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.

I think this is a bad idea for several reasons.

Storing the database configuration in the database brings some rather bizarre
chicken and egg scenarios of not being able to configure the database, fix a
problem, troubleshoot or tweak without actually running the database:

 * you've just installed CouchDB but it won't start, you're now unable to edit
   the configuration

 * your site is under high load, CouchDB is unresponsive and you quickly need to
   reconfigure the database and get things back on track, but you can't because
   to configure the database you need it running and it immediately gets bogged
   down with incoming queries

 * something screwed up with the database and you need to point CouchDB at an
   old backup version you have, but you can't because the database wont start

 * You're a system administrator and get a phone call in the middle of the
   night, the corporate CouchDB instance has gone down and you need to fix
   it. You only have access to the production machines via SSH from home,
   the web interface is only available on the company's Intranet. You need to
   edit the configuration to get things running again, but you can't from the
   terminal because you don't have a text-mode browser installed.

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

See above example of a Python library that can parse, serialise and validate INI
style configuration files. I am sure that similar libraries must exist for other
languages.

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

As I mentioned before, the INI style configuration is a de facto standard and we
should use it if we can for that reason alone.

I think it is a false argument to suggest that people dealing with CouchDB need
to know JSON - any corporate database will have many people all interacting with
it at various levels. You can't expect the system administrators to know or care
about JSON or to want to use a web based interface for configuration.

On Apr 10, 2008, at 4:22 PM, Daniel Yokomizo wrote:
> 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.

This smells like over engineering or YAGNI to me. :)

-- 
Noah Slater - The Apache Software Foundation <http://www.apache.org/>