And I’ll add that there’s a need, at least for folks like Cloudant, for a config store higher than an individual cluster. I’m not sure if that’s a general need so I won’t go on about it too much, but it indicates that the backend of _config should be pluggable; those with the same need could pull from etcd, Consul instead of the _config database or default/local.ini.
Finally, there’s a bootstrapping concern; new nodes should get their configuration from whatever this new system is before they start up completely. B. > On 9 May 2015, at 12:52, Robert Samuel Newson <[email protected]> wrote: > > > CouchDB does need a good answer to cluster-wide configuration. At Cloudant, > we use Chef to write default.ini (from a template) and our operators are > responsible for ensuring any local changes are made to the appropriate nodes. > It’s not an ideal situation. > > /_config is a valuable feature and I am against removing it; in 2015 we > should not have to restart a node to change a configuration setting. > > So, let’s focus on solutions instead. > > The "token ring" idea has not been expressed in detail yet, has it? I’ll > defer opinion until then. > > We already have an answer for cluster-wide agreement on node membership and > database shard mappings; the _dbs and _nodes databases are replicated to all > nodes. > > One answer, therefore, is to move all config items into a _config database > and do the same. The only parameter that must remain outside of that is the > path to the _config database itself. This could move to a command line > parameter (i.e, "> couchdb -config /path/to/_config.couch"). Caching would > also be important, like it is for _users. > > Another is to use something like etcd, Consul or ZooKeeper as a consistent > store to complement our available database. > > In any solution, a distinction between cluster-wide and node-local settings > will need to be made. It should be possible to override a cluster-wide > setting on a per-node basis, and those settings should be pushed to all > nodes, so that new nodes, or recovering nodes, can receive those changes too. > > B. > >> On 9 May 2015, at 00:30, Alexander Shorin <[email protected]> wrote: >> >> On Sat, May 9, 2015 at 2:18 AM, Robert Kowalski <[email protected]> wrote: >>> Related: _config not being available on the front-cluster http >>> interface is also confusing - I did not expect that when making the PR >>> :( >>> >>> See https://issues.apache.org/jira/browse/COUCHDB-2683 >>> >>> We will remove the config tab from Fauxton but everyone will try curl >>> if the tab is not in Fauxton anymore. >> >> This is a broken user experience ): >> There is no other way now as to explain every user that /_config isn't >> available anymore for cluster interface. We just need to fix that >> problem. I have it in my list to think and work on for this month. >> >> -- >> ,,,^..^,,, >
