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!
