couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <matt.good...@gmail.com>
Subject Re: Configuration Load Order
Date Tue, 19 Jul 2011 08:22:40 GMT
On 19 July 2011 02:22, Noah Slater <nslater@apache.org> 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
do.

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

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

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