couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <m...@jan.io>
Subject Re: [PROPOSAL] Include replication scheduler in 2.1
Date Wed, 19 Jul 2017 18:04:33 GMT
+1

Cheers
Jan
--

> On 17. Jul 2017, at 20:35, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> 
> +1 (assuming that's +1 in favor of releasing with scheduling replicator)
> 
>> On Sun, Jul 16, 2017 at 7:54 PM, Nick Vatamaniuc <vatamane@gmail.com> wrote:
>> +1
>> 
>>> On Jul 16, 2017 17:14, "Joan Touzet" <wohali@apache.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> *Per the CouchDB bylaws, this is a concrete proposal that will default
>>> to lazy consensus in 72 hours (2017.07.19 ~21:00).*
>>> 
>>> As we approach release candidates for v2.1 (see next email), we have one
>>> major decision left to make: whether or not to include the scheduling
>>> replicator in 2.1.
>>> 
>>> Arguments for inclusion:
>>> 
>>> * New feature allowing CouchDB to manage more replication jobs at
>>>  the same time by switching between them / starting / stopping.
>>>  From the documentation:
>>>  * Handles failing jobs more gracefully (exponnential backoff).
>>>  * Includes a new pair of API endpoints: _scheduler/jobs and
>>>    _scheduler/docs with enhanced information and an updated state
>>>    machine for replication jobs.
>>>  * Shared connection pool improves network resource usage and
>>>    performance, especially with large numbers of connections to
>>>    the same source/target.
>>>  * Improved request rate limit handling.
>>>  * Improved recovery from long but temporary network failures.
>>>  * Better handling of filtered replications.
>>> * Feature includes its own tests, which all pass.
>>> * Feature is fully documented.
>>> * Cherry-picking out the scheduling replicator commits from the
>>>  ~190 commits since then (all bugfixes and minor improvements) is
>>>  labour intensive for the release team, and possibly error prone.
>>> 
>>> Arguments against inclusion:
>>> 
>>> * It has been ~9 months since the 2.0 release. Many bugs have been
>>>  found and fixed.
>>> * A new release without the scheduling replicator would provide
>>>  risk mitigation for users who need those bug fixes but are risk-
>>>  averse to new features.
>>> * Scheduling replicator has not seen much real-world testing. Bugs
>>>  may surface in a 2.1 release that could destabilise existing
>>>  installs being upgraded.
>>> 
>>> I've thought a lot about this issue, and would like to propose that we
>>> release 2.1 *with* the scheduling replicator included. My reasoning is
>>> that the benefits outweigh the potential downsides. If necessary, we
>>> can release a 2.1.1 in the following weeks with urgent bug fixes to
>>> the scheduling replicator if necessary.
>>> 
>>> Another alternative would be to ~simultaneously release a 2.1 from just
>>> before the scheduling replicator landed (~190 commits ago), then a 2.2
>>> from the HEAD of the master branch with all the subsequent fixes. 2.1
>>> would be missing these more recent fixes, but it would again avoid the
>>> massive cherry-picking operation necessary to port all of them to the
>>> 2.1 branch without the scheduling replicator. I'm -0 on this because
>>> of the confusion it might create with release announcements, but
>>> wouldn't block if that was the desired path forward.
>>> 
>>> Developers, please make your voices heard! :)
>>> 
>>> -Joan
>>> 


Mime
View raw message