wohali commented on issue #593: Allow bind address of 127.0.0.1 in _cluster_setup for single node URL: https://github.com/apache/couchdb/issues/593#issuecomment-313975347 OK, so I've started implementation, and ran into a concern during the process, contingent upon the fact that the setup app currently determines if a cluster is "finished" setup by checking for the presence of `_global_changes`, `_users` and `_replicator` as databases on the clustered endpoint. This may not always be true, especially for `_global_changes`. One scenario that worries me a lot: imagine an automated deployment tool (Chef/Puppet/Ansible/etc.) using `GET /_cluster_setup` to validate that nodes are functional. In a cluster where one of the 3 default databases has been removed (e.g. `_global_changes`) and the tool uses the output of `GET /_cluster_setup` to determine whether to (re-)finish setup, a never-ending create/delete loop might be created. Even if the action was manual, we know there are situations where a create/delete/create cycle can lead to race conditions and other badness. So, the changes are: * Update to the `finish_cluster` endpoint to allow an additional parameter, `ensure_dbs_exist=["db1", "db2", ...]` where those _clustered_ databases will be checked for and created if they do not exist. Matching the current behaviour, the default list is `["_users", "_replicator", "_global_changes"]`. * Update to the `GET /_cluster_setup` method to allow optionally specifying `ensure_dbs_exist` to match the `finish_cluster` endpoint. * The `"action": "enable_single_node"` will allow binding to 127.0.0.1. It will also set `[cluster] n=1`. The action will also take the `ensure_dbs_exist` parameter. * Fauxton will need to be updated for the single-node behaviour. I'm not planning to expose the `ensure_dbs_exist` parameter in that UI; if people want non-standard cluster setup behaviour they can use the endpoint directly. ---------------------------------------------------------------- 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: [email protected]
With regards, Apache Git Services
