On 19 July 2011 02:22, Noah Slater <[email protected]> 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.
>
>
