couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Configuration Load Order
Date Wed, 17 Aug 2011 11:28:38 GMT

On 16 Aug 2011, at 23:03, Randall Leeds wrote:

> Agreed also. We still have a question about load and save order.
> One idea would be to track the .ini file from whence an option came. If an
> option comes from a local.ini or local.d/ file it could be updated in place.
> If it comes from a default.ini or default.d/ file, updates should be placed
> in local.ini. This would make the most sense to me.

I think our previous discussion holds on this.

CouchDB should not be modifying default.ini, default.d/*, local.ini, or local.d/* at all.
Anything CouchDB needs to write back to the config files should be put in runtime.ini, or
runtime.d/* only. Sorry, I couldn't help giving the whole "generated" thing a new name while
I was at it. In this case, it means that someone might put a password hash in local.ini, and
CouchDB would later write out an updated password hash to runtime.ini, but that is fine. The
runtime.ini file is loaded after local.ini, so as long as it is in place, the setting there
would override any previous values.

To be honest, getting back to a previous sub-thread of this thread, if CouchDB is needing
to write back at all, that might be a good indication that the config value should be held
in CouchDB in the first place. If you look at how MySQL uses its config files, for example,
you see that all the values there are values that the database needs BEFORE IT INITIALISES
and is ready to serve requests. Anything else is kept within the MySQL instance itself. If
we were going to remove anything from the ini files that isn't needed for database initialisation,
what would we loose? I am guessing the users and passwords would go, which would obviate this
issue. MySQL keeps its user information in MySQL.


> I would also be in favor of enforcing a load order that supports a directory
> structure like:
> local.d/
>  010-stuff.ini
>  020-others.ini
> 
> We don't need to ship anything like that by default. I think right now we
> take the load directories on the command line, no? It'd be nice if the order
> of resolution within those directories was well specified.

This is how the system is designed.

The code that loads files from a directory is:

    for file in "$1"/*.ini; do
        if [ -r "$file" ]; then
          _add_config_file "$file"
        fi
    done

This should list files in some alphanum sort order, as demonstrated:

nslater@tumbolia:~$ echo test/*
test/b test/c test/d test/e test/f test/h test/i test/j

This means that with an example full config directory, the load order should look like:

default.ini
default.d/001_foo.ini
default.d/002_bar.ini
local.ini
local.d/001_foo.ini
local.d/002_bar.ini
runtime.ini


Mime
View raw message