On 19 July 2011 02:22, Noah Slater <nsla...@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. > >