couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [jira] [Commented] (COUCHDB-2016) Plugins meet BigCouch
Date Mon, 06 Jan 2014 12:36:26 GMT
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 <bchesneau@gmail.com> wrote:

> 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=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)
>> 


Mime
View raw message