couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Configuration in CouchDB 2.0
Date Thu, 23 Apr 2015 16:10:52 GMT
Hi Robert,

On Thu, Apr 23, 2015 at 6:53 PM, Robert Kowalski <rok@kowalski.gd> 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

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.

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.

--
,,,^..^,,,

Mime
View raw message