wohali commented on issue #1781: Cluster Setup doesn't set consistent admin user URL: https://github.com/apache/couchdb/issues/1781#issuecomment-445977015 So there's 2 things you've left unaddressed here that I think need to be explained before I can discuss your response. 1. Why are we bothering to pass in both a `username/password` and `remote_current_user/password` pair if we require everything to be identical on all nodes? I would have thought that the `username/password` pair is the admin user we are trying to create everywhere, and the `remote_current_user/password` pair is the pre-existing admin user on that remote node we need to use to affect change on that node. 1. In an ideal world, assuming these two pairs of data are allowed different, why couldn't the `remote` version be some unique auto-generated set of creds on every node? I'm looking towards CouchDB 3.0 where we intend to completely remove admin party. In this situation, nodes will stand up with an arbitrarily generated admin/password pair, and there is no way (short of pre-seeding your own `local.ini` file) that Couch could possibly know `a priori` what the eventual cluster's admin/password pair would be. **But**, if it printed out its randomly generated u/p on startup (similar to how `dev/run` does it), that info could be gathered by a script or a human and plugged into the cluster wizard on setup. These would be the `remote` credentials, and the primary `username/password` pair passed in via JSON would be the newly created admin user, with the unified salt. (The wizard could then *also* remove the autogenerated u/p credentials, as a bonus feature to be added later.) 2. Assuming for whatever reason we don't want to do 1, why are we even bothering to pass in 2 sets of credentials, if the only way this works is if we forcibly manually set the creds on every node to be identical at the start? I notice you've removed the second set of credentials in your example, but that still has confusion with the difference between the two sets of creds - if we're forcing it via the first step, why bother even supporting passing them in? 2. The situation where a different admin password is set on a node and I forgot to pass in the correct `remote_current_user/password` should have been an error, no? It shouldn't have been able to make *any* change to that remote node. And yet we got back an `{"ok":true}`. That's got to be wrong.
---------------------------------------------------------------- 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
