Great insight Benoit, could you post this to JIRA, so we have it on the ticket?
Best Jan -- On 06 Jan 2014, at 09:41 , Benoit Chesneau <bchesn...@gmail.com> wrote: > 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) >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
