couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Configuration Load Order
Date Wed, 17 Aug 2011 13:24:44 GMT

On 17 Aug 2011, at 02:04, Jason Smith wrote:

> The American quip goes: the professor who never even ran for dog
> catcher presumes to tell the president how to do his job. Developers
> who spend all day in ./utils/run pontificate about good daemon
> behavior in an OS or distribution.

Just to clear up the ad hominem before I continue. Most of your arguments are directed comments
I have made. But of course, I built the original system, and used my experience as a Debian
developer to inform my decisions about best practice. I've also been a sysadmin for a number
of companies, and in fact, I have never used ./utils/run for anything, so…

> My proposal is already implemented. Now I say promote HTTP config
> (Futon) over .ini files when possible. Integrators, packagers, and
> advanced sysadmins can attack the .ini files just as before.

The more I've reflected on this thread, the more I think that the ini files should be for
pre-initialisation settings. Conversely, anything post-initialisation should probably be moved
to a special CouchDB database. So it seems we are in agreement here.

> Now we are invoking use cases of versioning the config, and auditing
> it. Wow! 

In many setups, the basic text file configuration of a system is versioned and audited. Think
again of the MySQL daemon configuration versus the users and permissions. Debian packages
themselves are, of course, a great example of this. Each package ships with it a default configuration
that gets the daemon up and running. It would be much harder to do this if that process involved
starting CouchDB and then communicating with the database. It would, in the very least, involve
writing a custom tool that speaks to CouchDB. For the basics, you want to be able to just
move a file to the correct part of a filesystem.

> Config files that change themselves are bizarre and scary.


> Admins, passwords, and non-boostrappy configuration over HTTP seems
> more Couch-like, more "of the web," and more relaxed.


> Take a MySQL admin, or an admin of Drupal, Wordpress, Moodle, Joomla,
> or pretty much any big PHP application. Tell them this: "You have to
> get CouchDB up in the first place. So you edit some config files. Once
> it's up, you connect with your client/browser. It assumes you are an
> admin, and you complete installation over that interface." They would
> respond: "Yeah, sure."


> I do not buy the "misbehaving Couch" scenario. Firstly, how common is
> that? After installation and confirmation, daemons get pretty stable.
> If a misconfiguration totally destroys the couch, well, they are still
> plain text. As before, load emacs and go for it!

The argument was that if daemon configuration lives inside the daemon, and you mess it up,
then you wont be able to run the daemon to edit the daemon configuration. As long as there
is a separation of concerns, this shouldn't be a problem. You shouldn't be able to hose you
CouchDB installation through the configuration options hosted within CouchDB. Think of it
in terms of a managed hosting environment. As the service provider, you want to be able to
let your customers configure users and permissions and URL handlers, etc. But you don't, necessarily,
want them to be messing about with the daemon options.

> Finally, I am basically happy with the Couch config. It's quirky but
> not too bad. I only hope to share a fresh perspective: the viewpoint
> of people for whom couch is just another daemon, like MySQL or httpd
> or cron.

Why is it quirky?

Luckily, I have been building the system from that perspective from the start!
View raw message