wohali opened a new issue #1595: Improve config subsystem
URL: https://github.com/apache/couchdb/issues/1595
 
 
   CouchDB's configuration subsystem is fragile, presents deployment issues for 
packaging and containers, and needs to be reworked.
   
   _Numbers in "Expected Behaviour" below match up with the same number under 
"Current Behaviour."_
   
   ## Expected Behaviour
   1. Single place for server admins to go to change server settings in the 
filesystem
   1. Single place for developers to define default values for config settings, 
checked into source control
   1. Default values can be fed into documentation
   1. A way to separate out package/distribution-specific changes from local 
admin-specific changes; i.e., a package or container update should never have 
conflicting changes with local admin-introduced changes
   1. On API-based config updates, the definition of the config should be 
changed where it's made, not in the last file in the config chain
   
   ## Current Behaviour
   1. Mix of `vm.args`, `local.ini`, `local.d/*.ini`, unsanctioned changes to 
`default.ini` and `default.d/*.ini`, `sys.config`, `.erlang`, `.erlang.cookie`, 
 ...
   1. Default values are scattered throughout the code, wherever we invoke 
`config:get/3`
   1. Documentation lags behind implementation and is only updated when someone 
notices, remembers, or files a bug, meaning we potentially have forever-wrong 
content out on docs.couchdb.org
   1. `default.d/*.ini` and `local.d/*.ini` actually works OK, but is a bit 
obscure; even after marking `local.ini` as a config file in the `.deb` package 
we still get reports like #1594 
   1. Only the last file in the config change is ever updated when modifying 
the config via the HTTP API, see #777 
   
   ## Possible Solution
   Up for discussion.
   
   ## Context
   Everything under "Current Behaviour" above represents a problem I, or 
someone else on the CouchDB dev team, have run into.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to