[
https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230445#comment-14230445
]
Robert Kowalski commented on COUCHDB-2390:
------------------------------------------
I think we should not ship a broken feature and add a text next to it stating
that it currently does not work. We don't have a timeframe for a config db or
even a concept so the feature probably stays broken for a longer period.
I am not sure what the use case for a config for one node is, given that I just
change the config on one node and I then have to change the config on another
node. This will easily lead to different configs from not reading the text
carefully and also human error by manually entering the config on all nodes and
create really hard to find issues which are not fun to support on the mailing
list or in the issue tracker.
Less error prone for a dev-cluster is just editing our single config file which
is copied to each node on ./dev/run - maybe we can remove the config settings
and just add a text that refers to this dev-config-template. For a production
setup people would use config management anyway.
</bikeshed>
Possible way to get to a solution:
I think I already heard some ideas from [~janl] how we could solve the problem
in the backend in a better way and as 2.0 is not shipped tomorrow I would like
to ask if we can wait a bit until we make a hotfix either by deleting the
section or writing a text next to it that it does not work.
I also remember that we still have to add an easy way for a single node setup
from the backend - I think we might have a better idea how to proceed and how
to decide with the config when we finally have an easy setup for single nodes
(or not).
For the CouchDB Developer Preview that was released at ApacheCon Jan and me
built a setup wizard for the backend and frontend which also might have a use
case for setting an initial config. It is located at
https://github.com/apache/couchdb-setup and
https://github.com/robertkowalski/couchdb-fauxton/compare/setup
The point I am trying to make is that the change of just adding a notice or
deleting the config at all is a thing we can do in 1hr. But as there is still a
lot that will happen before the 2.0 release we will reach a point in the next
year where we can make a better decision because we know more and have more
possibilites.
At the point where we can decide in a better way as other features may have
landed I would also like to include Sean in the discussion from the UX point of
view as he also has a good point of view how our users use our product.
> 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
> Assignee: Ben Keen
> 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)
