couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: [DISCUSS] Deprecating _externals?
Date Mon, 27 Oct 2014 21:11:37 GMT
They've always been a bit of an odd beast. In hindsight the best
solution would've to remove the daemons/externals APIs altogether when
the changes feed was introduced. I agree that they'll make little to
no sense in a cluster, plus once you get around to managing a cluster
adding the HAProxy/(runit|supervisord|upstart|whatever) combo should
be easy and something that we can either document directly or allow
the community to document.

I'd be +1 to remove it. As you point out its basically just a bad
reimplementation of behavior that already exists in much more
stable/mature technologies (HAProxy/nginx) that are much better
documented.

Paul

On Mon, Oct 27, 2014 at 3:58 PM, Joan Touzet <wohali@apache.org> wrote:
> Today, someone came to the #couchdb channel asking about
> _externals. For a long while it's been on my mind that perhaps
> we should deprecate the entire _externals feature for a number
> of reasons:
>
>   1. Couch is not a great reverse proxy. Making it into one is
>      as hard as rewriting nginx or haproxy in erlang. It's a
>      distraction to our development team and far outside our
>      core competency.
>
>   2. In a clustered CouchDB (the default in 2.0), the
>      assumptions around externals change drastically. For an
>      _external to work, it must be stateless and not rely upon
>      multiple sequential requests to hit the same node (assuming
>      the standard n-node cluster + a load balancer/reverse proxy
>      at the front.)
>
>      People who wrote a CouchDB 1.x external could reasonably
>      expect to write an old-school singleton app (i.e., the only
>      copy of that external process running, on a single machine).
>
>      If they engaged in any of a number of bad behaviours for
>      distributed systems - storing content on local disk, locking
>      or blocking connections to other services/databases in a
>      "single-threaded" pattern, or even expecting CouchDB not to
>      possibly introduce a conflict or "read your writes" - they
>      will probably fail outright at best, or at worst introduce
>      subtle and confusing behaviour.
>
> TL;DR: We're changing the contract we give to _externals in a
> reverse-compatibility-breaking way. We either need to document it
> straight up, along with all of the admonishments required for
> people who expect it to operate the same as in 1.x, or we need to
> remove it.
>
> My opinion is that now that the default CouchDB rollout will be
> a cluster with a reverse proxy, that _externals should be exposed
> through the load balancer, which can then reference 1 or more
> processes distributed either on the same CouchDB nodes, or on
> different hosts should compute needs demand it.
>
> The exception here would be a single-node CouchDB, which could
> still use the same approach. However I don't see the issue with
> deploying an haproxy on that same node and using the same approach
> I describe above.
>
> Thoughts, comments, suggestions?
>
> -Joan

Mime
View raw message