Just a note: anyone actually *upgrading* from 1.6 isn't going to have anything but a cluster-of-one, so I think that limiting the web UI to cluster-of-one setups is perfectly fine (nobody is losing capability). Any cluster-of-N deployment is going to be new by definition, so having to use a new set of config tools to manage it doesn't seem unreasonable to me.
Cheers, Eli On Thu, Jul 2, 2015 at 2:00 PM, Jan Lehnardt <[email protected]> wrote: > >> On 02 Jul 2015, at 22:50, Alexander Shorin <[email protected]> wrote: >> >> On Thu, Jul 2, 2015 at 11:31 PM, Jan Lehnardt <[email protected]> wrote: >>> I really like your attempt to preserve this 1.x-ism for small clusters. >>> >>> I’m not sure I feel really good about this though, for the same reasons >>> that Robert K outlined. >>> >>> I’d be more comfortable in saying 2.0 does not have any config screen >>> in Fauxton and for 2.1 we figure out cluster-wide configuration and then >>> that gets a Fauxton UI. >>> >>> For our 2.0 messaging then, we could explain that the 1.x-ism compatibility >>> release is 2.1 (or whenever this can land), so that people migrating from >>> 1.x need to be aware of this limitation, or wait until 2.1. >> >> I worry here that we'll generate a lot of talks by this like: > > I hear you! :) I worry too! > >> - Hey! What have you done with web ui? How should I configure CouchDB now? >> - We removed Config from Fauxton as it doesn't fits well cluster environment. >> - But I don't need a cluster and bag of problems it brings on! > > Like Robert’s proposal said, for “clusters of one”, we can just show the > config screen. > >> - Sorry, 2.0 is not friendly for simple setups... > > When we release 2.0 we can say that there are major changes and that for > that reason, some of the convenience of the 1.x series is temporarily > missing. And at the same time say, that we’ll add this back in 2.1. If > anyone needs the config screen, they can wait. > >> But still being able to just read per-node config via Fauxton is a >> good idea. And even for clusters, it makes a sense: it gives the way >> to put some specific node into maintenance mode right from Fauxton >> (while there is no any cluster management page). > > Like Robert explained, expressing this in the UI is not trivial, the > team has worked hard on this. I agree the feature is useful, but if > we can’t make it usable, we have to keep working on it and maybe > land a solution later, e.g. in 2.1. :) > > * * * > > Or we say Fauxton configuration is a must for 2.0 and this is now a > blocker, until we have a story for a consistent config store that works > in small and large clusters. > > I’m fine with either way, but we must accept that a new feature can > take a lot of time and we are rather overdue with 2.0 as it is, hence > the “documentation” workaround explained above. > > Best > Jan > -- >
