couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <>
Subject Re: Configuration Load Order
Date Tue, 19 Jul 2011 08:22:40 GMT
On 19 July 2011 02:22, Noah Slater <> wrote:

> On 19 Jul 2011, at 00:57, Randall Leeds wrote:
> >> My understanding is that local.ini is that generated.ini.
> Nope.
> The default.ini file is for the default configuration we ship with CouchDB,
> or for downstream distributions to include a default config. The local.ini
> file is for the local system administrator to customise the setup, without
> changing the system defaults, so that any future updates can be made without
> over-writing local changes.

I agree with this.

Also, at least from my experience on Debian-based systems, files from a
something.d directory are *included by* the main something.ini file. So,
writing to local.ini seems wrong as it's not the end of the chain.

> What I am suggesting is that we add an additional generated.ini layer that
> sits on top of that, and lets CouchDB write out run-time configuration
> changes. Each layer acts as insulation from loosing changes in the previous
> layer.

This makes sense to me. Personally, I don't think a
generated.ini/generated.d pair is needed - just a single generated.ini would

As well as ensuring changes are written to the last .ini file in the
configuration chain a generated.ini would act very nicely as a per-instance
configuration for when multiple CouchDB instances are run from the same,
read-only installation, i.e.

    default.ini/default.d  --  CouchDB default config, system-wide (R)
    local.ini/local.d  --  local sysadmin's config, system-wide (R)
    generated.ini  --  per-instance config (RW)

As such, I would suggest naming generated.ini something more like

- Matt

> >> I'm willing to patch the read order to make sure changes get written to
> local.ini however.
> It is my current opinion that this breaks expected behaviour as an easy fix
> for an unrelated problem — namely, where to write config changes to.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message