Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.216.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <JIRA.12687329.1388870014384.44475.1388930030648@arcas>
References: <JIRA.12687329.1388870014384@arcas>
 <JIRA.12687329.1388870014384.44475.1388930030648@arcas>
From: Benoit Chesneau <bchesneau@gmail.com>
Date: Mon, 6 Jan 2014 09:41:55 +0100
Message-ID: 
 <CAJNb-9p+m3=sjyZXzyKpSQ59DcsFwr=--cis-C2nnv6yrLEiig@mail.gmail.com>
Subject: Re: [jira] [Commented] (COUCHDB-2016) Plugins meet BigCouch
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2c83ca61d9c04ef493cc8

--001a11c2c83ca61d9c04ef493cc8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 5, 2014 at 2:53 PM, Jan Lehnardt (JIRA) <jira@apache.org> wrote=
:

>
>     [
> https://issues.apache.org/jira/browse/COUCHDB-2016?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D138625=
58#comment-13862558]
>
> Jan Lehnardt commented on COUCHDB-2016:
> ---------------------------------------
>
> I talked this over a bit with [~rnewson].
>
> Money quote: =93<rnewson> so couchdb plugins are erlang applications that=
 we
> have scripting to ease their integration into the couchdb release (and th=
e
> inverse).=94
>

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


>
> 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 releas=
e.
> The difference from regular release updates is that these releases would =
be
> triggered by CouchDB itself (e.g. the couch_plugins application). We woul=
d
> 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=92t have=
 to
> worry about nodes that don=92t receive an update instruction. Allowing th=
is
> 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: https://issues.apache.org/jira/browse/COUCHDB-2016
> >             Project: CouchDB
> >          Issue Type: New Feature
> >          Components: Plugins
> >            Reporter: Jan Lehnardt
> >
> > Currently Plugins don=92t work with BigCouch. Two options that I can se=
e
> 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 wit=
h
> the rest of CouchDB as an Erlang release and do not allow dynamic updates
> of apps.
> > I=92d prefer 1, but any other options are welcome too.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1.5#6160)
>

--001a11c2c83ca61d9c04ef493cc8--