[
https://issues.apache.org/jira/browse/COUCHDB-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863005#comment-13863005
]
Benoit Chesneau commented on COUCHDB-2016:
------------------------------------------
copy-paste of the ml response
On Sun, Jan 5, 2014 at 2:53 PM, Jan Lehnardt (JIRA) <[email protected]> wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862558#comment-13862558
]
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 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 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: https://issues.apache.org/jira/browse/COUCHDB-2016
> 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
(v6.1.5#6160)
