> 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 --
