couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2016) Plugins meet BigCouch
Date Mon, 06 Jan 2014 14:21:51 GMT


Benoit Chesneau commented on COUCHDB-2016:

copy-paste of the ml response

On Sun, Jan 5, 2014 at 2:53 PM, Jan Lehnardt (JIRA) <> wrote:


Jan Lehnardt commented on COUCHDB-2016:

I talked this over a bit with [~rnewson].

Money quote: “<rnewson> so couchdb plugins are erlang applications that we have scripting
to ease their integration into the couchdb release (and the inverse).”

I suggested that a long time ago and imo that's a good idea, see below my comments

There are multiple issues intermingled here:

1. How to (un)install and start a CouchDB Plugin on an installation that uses Erlang Releases
(BigCouch & rcouch & up)?
2. How to ensure a plugin gets installed into every node of a cluster?

3. How to cleanly upgrade a plugin when you upgrade a node (state recovery, and others termination

As for 1., Erlang Releases can be upgraded to newer versions while they are running. A plugin
installation is simply an upgrade to a newer release. The difference from regular release
updates is that these releases would be triggered by CouchDB itself (e.g. the couch_plugins
application). We would have to figure out how to do version numbers in this case and everything
else that retains Erlang Release semantics.

This is where there is a problem if we consider to have legit release vs custom release. With
custom release there are no problem, the users constructs its release and set the initial
version number then they choose which applications to upgrade.

In legit releases, we are providing the relup, deciding which apps to upgrade/remove etc...

The idea I had but I didn't have time to implement it yet was to construct the relup dynamically
on upgrade by merging the "core" relup containing all the base and telling how to upgrade
with a user relup only taking care about the plugins. In that case a "make relup" will construct
the final relup file and upgrade the release. Each release will be numbered 

"X.Y.Z-custom-P" or something. Where P is the local release version increment that is used
for the plugin actions (add/remove/upgrade/resetr) and X.Y.Z the base version number (apache-couchdb)

By using this system, a plugin could provide its own relup. An "update" action will update
the local relup file and then update the release. 

2. Installation of plugins should be done on each node separately. Once a plugin is installed
on all nodes, the nodes can be upgraded as per 1. to activate the plugin. The API for this
could disallow installation and upgrade if the cluster is in a unhealthy state. That way,
we don’t have to worry about nodes that don’t receive an update instruction. Allowing
this for unhealthy clusters could be tackled later, but is punted on for now.

I disagree. The user should not have to care about where the nodes are. Imo once a plugin
is installed the code should be sent to each nodes. The release upgrade could then be handled
from one node, eventually depending on the zone, so a user could batch N upgrade and if anything
wrong happen rollback.

In the same vein a node should be able to tell its current state to the api request saying
if it can accept this call or not (the plugin have been upgraded or not).  One another reason
to version our Rest API btw.

(small details, the title should be "Plugins meet Erlang Releases" because some people will
also have these problems with a cluster of isolated couchdb erlang nodes ;)

> Plugins meet BigCouch
> ---------------------
>                 Key: COUCHDB-2016
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: Plugins
>            Reporter: Jan Lehnardt
> Currently Plugins don’t work with BigCouch. Two options that I can see so far:
> 1. Find a way to dynamically install plugins into a cluster, surviving offline nodes
that get a delayed installation on recovery (or only allow plugins into a fully online cluster).
> 2. Make plugin building a static affair where plugins are installed with the rest of
CouchDB as an Erlang release and do not allow dynamic updates of apps.
> I’d prefer 1, but any other options are welcome too.

This message was sent by Atlassian JIRA

View raw message