couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Setting up CouchDB 2.0
Date Thu, 25 Sep 2014 18:06:24 GMT
On Thu, Sep 25, 2014 at 7:56 PM, Nick Pavlica <> wrote:
> -The short version:
> I would like to propose that CouchDB be developed and maintained separately
> from a management GUI.”

That's still would be possible. The main idea of Jan's proposal is to
simplify the cluster setup process using Fauxton UI and magic /_setup
helper. But that doesn't means that you won't be able to do the same
manually from command line interface and using plain old text configs.
Just a little bit more work to do in this case for you.

> -The longer rambling version:
> I would like to see CouchDB 2.x+ adopt a model that resembles that of Riak,
> Cassandra, and others, where there is a core server and everything else is
> optional.  It’s so easy to setup a Cassandra and Riak server or cluster
> from the command line with just a bit of good documentation.  I really like
> the fact that they are decoupled from an administrative tool like Futon or
> Faxuton.  By decoupling the admin GUI’s from the database, it paves the way
> for others to create new GUI tools, and reduces the effort to release new
> database versions.  While taking a current build of the Master branch for a
> spin, I was trying to use Futon only to discover that it wasn’t ready for
> the changes made in 2.0.  After some discussion on IRC, I learned that it
> would be replaced with Faxuton.  Once I left Futon behind, and used the
> command line I was up and running.  In the end, it was much easier to work
> from the command line than trying to work with an outdated tool that was
> hurting more than helping.  This is not to say that Futon, and Faxuton
> aren’t great tools, but they add additional complexity, and development
> effort outside the core objective of a database.  Having a minimal database
> core also allows administrators to have a reduced burden when it comes to
> system administration because there are fewer system dependencies to
> update, manage, and distribute.  On small systems it isn’t as big deal, but
> the larger systems become, the harder they are to manage.  Additionally,
> having to interact with a UI makes it harder to setup a cluster with
> deployment tools like Chef, etc.  CoreOS, really highlights the need to
> reduce the administrative burden when managing large systems.  Here is a
> video that illistrates why/how CoreOS has striped down everthing but what
> is needed (  While not exactly
> relevant, it does convey the general idea.  It could be called CoreCouch,
> CouchCore, or … :)

CouchDB 2.0 has new project layout where each component lives in his
own repository and roughly plug-able: you can easily turn off
component you don't need (sure if they're not the core) and Fauxton or
docs are the such.


View raw message