On Sun, Jan 5, 2014 at 2:53 PM, Jan Lehnardt (JIRA) <j...@apache.org> 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) >
