couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <>
Subject Re: Configuration in CouchDB 2.0
Date Thu, 23 Apr 2015 17:04:19 GMT
Hi Alex,

not sure if I was telling the story the right way. See my responses inline.

On Thu, Apr 23, 2015 at 6:10 PM, Alexander Shorin <> wrote:
> Hi Robert,
> On Thu, Apr 23, 2015 at 6:53 PM, Robert Kowalski <> wrote:
>> This lead to bad errors a few workdays later which were hard to
>> diagnose - it was not obvious to our team why Couch is broken at all
>> and how to solve that issue.
>> My team works on a daily basis with and for CouchDB - this is why I am
>> quite worried about our users who just want to use CouchDB.
> I'm curious how did you figure on which (cluster/local) interface
> Fauxton is get served and why do you expect any errors? Just because
> for me, here logic is pretty trivial:
> HEAD /_config -> 200 OK -> render a button
>                               -> 40x -> don't render a button

I solved it exactly like that but that is not the point of my post. I
don't want to discuss implementation details of Fauxton, it is just
the introduction to my mail (as I thought the config problem was
solved with that solution until yesterday).

I am trying to tell the story of my team which is even working on
CouchDB on a daily basis. That means they know more about CouchDB than
new users and also even more than advanced users.

They used the backdoor config and got errors they never expected and
knew of. I am not sure if that is an user-experience we want to ship,
especially to folks which are new to CouchDB and want to try it out.

> This request need to make once when Fauxton loads first time and once
> again when user get login/logout - there is no point to show buttons
> for users which they cannot click.
>> Yesterday I thought which possibilities we have to avoid such scenarios:
>> A solution could be to also deactivate _config on the backdoor-ports.
>> But users can still make changes to the config-ini-files which are on
>> each node. And if we take away the config files, CouchDB is not
>> configurable any more.
>> At the last CouchDB Meetup Hamburg we discussed a "token ring" [1] for
>> configurations. This is neat but needs some work in the Erlang core.
>> I think there are a ton of other possible solutions.
>> For me the config is still a major issue after that experience. What
>> do you think?
> Deactivation /_config may be harmful, since you completely loose to
> configure node without restart. That's not cool at all.
> Remove Config button from Fauxton at all may be quick and dirty fix
> (if you suffers from weird random errors there), but this reduces UX.
> However, without _config on cluster/public interface it's already hurt
> a lot.

My story is meant as a real life example from folks that used the
_config endpoint on the backdoor ports on a three node cluster. This
could be done using curl, changing the ini file or Fauxton. The story
I try to tell is that folks will use those ports without knowing what
will happen, get horrible errors that look like random errors (because
of the loadbalancer) and the get disappointed from Couch. At least I
would as a user.

> Long-term and good solution is, obliviously, make /_config works on
> cluster interface, there is no doubt. I even would like to take this
> task and would be glad if some core developer will mentor me on
> implementation idea and on the very first steps.
> --
> ,,,^..^,,,


View raw message