[
https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223586#comment-14223586
]
Ben Keen commented on COUCHDB-2390:
-----------------------------------
How about something like this. It’s fussy, but I think it’s better than
removing the config + admin sections altogether. And it will at least allow the
config page to function properly in both a cluster and non-cluster setup.
On the config page, detect the couchdb version.
*1.x*
Continue showing it just like now. No problemo.
*2.x*
Case 1: If CORS *isn’t* enabled on one or more more of the nodes in the
cluster, add a message at the top of the screen saying:
{quote}
One or more of the nodes in your cluster doesn’t have CORS enabled. If you want
to update any of the config settings below you will need to manually make the
change to each node. Here are the list of nodes on your cluster:
node1 (CORS enabled)
node2 (CORS not enabled)
node3 (CORS not enabled)
If you enable CORS on all servers you can update all node configs with a single
action. Learn more.”
{quote}
- All the nodes would be links to the config page on that node.
- The "Here's how to do it" could maybe open up a modal. Whatever. Something to
explain what the heck’s going on and how they can solve it.
- We can use the new /_membership endpoint to get the list of nodes in the
cluster. Finding out if they have CORS enabled should be as simple a matter as
doing a GET request to them from the client, e.g. the _config endpoint (no?).
Case 1: If CORS *is* enabled for all nodes in the cluster, add a message
saying:
- “You are on a cluster. The changes you make here will be applied to
all node config files.”
Then when a user deletes/adds a new config option, behind the scenes do
*multiple* POST/DELETES to all nodes. Only if all N succeed do you show a
success message [be nice to have rollback on any errors here, too].
I think the same logic/blurb can be used work for the Create Admin pages.
> Fauxton config, admin sections considered dangerous in 2.0
> ----------------------------------------------------------
>
> Key: COUCHDB-2390
> URL: https://issues.apache.org/jira/browse/COUCHDB-2390
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: BigCouch, Fauxton
> Reporter: Joan Touzet
> Priority: Blocker
>
> In Fauxton today, there is are 2 sections to edit config-file settings and to
> create new admins. Neither of these sections will work as intended in a
> clustered setup.
> Any Fauxton session will necessarily be speaking to a single machine. The
> config APIs and admin user info as exposed will only add that information to
> a single node's .ini file.
> We should hide these features in Fauxton for now (short-term fix) and correct
> the config /admin creation APIs to work correctly in a clustered setup
> (medium-term fix).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
