couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Configuration Load Order
Date Wed, 17 Aug 2011 14:07:01 GMT
On Wed, Aug 17, 2011 at 8:24 PM, Noah Slater <nslater@apache.org> wrote:
>
> 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…

Sorry, I'll cut that out on the dev@ list. While I addressed many of
your points later on, the motivation to chime in came directly from
Randall's post. Out of the blue comes discussion of couchctl, and
password management tools, and config file
convention-over-configuration. My feeling is make configuration
simpler than it is today.

Looks like you and I are in broad agreement on the details. Thanks for
the feedback!

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

I have no difficulties thinking of it in terms of a managed hosting
environment :) and I wrote config_whitelist because users were
changing their listen address and port, taking their couches offline.
Totally agree.

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

The .ini file that edits itself. There are probably some servers out
there which do that, but as you know, sysadmins expect /etc files to
stay put! Many use CVS to manage them, as you noted.

Hence, I like the generated.ini idea because as a sysadmin, during
peacetime (couch is running fine) it is just an opaque file blob I
need to back up. During wartime (couch is crashed/misconfigured), I
can dig into it with emacs and troubleshoot.

-- 
Iris Couch

Mime
View raw message