In fact I am reporting this issue right now in this thread. I also reported it yesterday in the meeting and was asked to write to the ML.
It is not really a bug, like a runtime exception that I am reporting. The errors I describe are originating from the misuse of _config and the resulting issues look like bugs to users and cause a lot of confusion. The intention of my mail is to get feedback on atomic config changes (e.g. a token ring). At least for me this issue is a blocker for Couch 2.0 after my recent experiences where I had help a colleague. On Thu, Apr 23, 2015 at 7:11 PM, Alexander Shorin <[email protected]> wrote: > Well, summarizing your story, if you got such random and horrible > errors, why not to report them? Sure, everything could and should be > fixed (: But things cannot be fixed if nobody known that they are > broken. > Here you a poster about: http://i.imgur.com/UqIzZZH.jpg > -- > ,,,^..^,,, > > > On Thu, Apr 23, 2015 at 8:04 PM, Robert Kowalski <[email protected]> wrote: >> 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 <[email protected]> wrote: >>> Hi Robert, >>> >>> On Thu, Apr 23, 2015 at 6:53 PM, Robert Kowalski <[email protected]> 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. >>> >>> -- >>> ,,,^..^,,, >> >> Cool!
