[Bug 1212481] Re: [FFE] CouchDB 1.4.0 needed to work with Erlang 16.b.1

[Andrew Starr-Bochicchio]

Hi Jason,

I'm inclined to go ahead and upload
lp:~jderose/ubuntu/saucy/couchdb/1.4.0 It LGTM and it's certainly the
way forward.

One last question, have you done any testing of python-couchdb against
this version?

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1212481

Title:
  [FFE] CouchDB 1.4.0 needed to work with Erlang 16.b.1

Status in “couchdb” package in Ubuntu:
  Triaged

Bug description:
  CouchDB 1.2.0 doesn't work at all with Erlang 16.b.1, so the current
  CouchDB package in Saucy is completely broken and should be removed if
  it can't be upgraded.

  To work with Erlang 16.b.1, we'll have to upgrade to the recently
  released CouchDB 1.4.0. The needed compatibility fixes are extensive
  and include upgrading CouchDB's internal mochiweb server, so
  backporting the needed changes to CouchDB 1.2.0 isn't practical.

  Following is an overview of the testing I've done, results, and known
  issues:

  == Unit Tests ==

  CouchDB 1.4.0 now has quite extensive unit tests, which I'm running
  during the build. These tests are (generally) passing fine when
  building with pbuilder, and when building in a PPA (i386 and amd64).

  Note I've not tried a build on armhf yet.

  There are a few unit tests that occasionally fail when building on
  Raring, but so far I haven't encountered this when building on Saucy.
  It is however possible to get successful builds on Raring, you just
  might have to retry a build or two.

  == Reverse Dependencies ==

  I've built several CouchDB consumers against my proposed CouchDB
  package in a PPA, on both Saucy and Raring. These reverse dependencies
  have extensive CouchDB using unit tests and are therefor a good
  measure of the correctness of my proposed CouchDB 1.4.0 package, and
  the quality of the upstream CouchDB 1.4.0 release.

  UserCouch: https://launchpad.net/usercouch
    * Good coverage of key configuration permutations (bind address, port, basic auth, oauth, file_compression)
    * Good coverage of SSL options, both for httpd and the replicator
    * Provides good confidence that CouchDB actually starts, and starts in a timely manner, across all config permutations
    * IPv4 and IPv6 tests

  Microfiber: https://launchpad.net/microfiber
    * Good coverage of core DB, doc, and attachment REST APIs
    * Deep tests for _bulk_docs API, testing both "non-atomic" and "all-or-nothing" update semantics
    * Basic view tests
    * Basic replication tests
    * IPv4 and IPv6 tests

  Dmedia: https://launchpad.net/dmedia
    * Complex, demanding application with lots of "real-world" test scenarios
    * Extensive view tests with complex map functions (but _count, _sum, and _stats are the only reduce functions Dmedia uses)
    * Full-stack replication tests with SSL (and client-side SSL certs)
    * Tests for complex conflict scenarios

  == Manual Testing ==

  I've done extensive manual testing with Dmedia. I peered 3 different
  computers and imported around 20k files into Dmedia, made sure all
  metadata got replicated between all peers. I ran through my standard
  battery of abuse using things like PurgeAll and DowngradeAll, and in
  all scenarios the library successfully converged to its equilibrium
  state in a reasonable amount of time.

  I've also done extensive manual testing with the `couchdb` binary package and its new upstart job. I confirmed that:
    1) The daemon is started when the package is installed
    2) The daemon starts during the boot sequence after a reboot and a cold boot
    3) All daemon processes are killed with `sudo stop couchdb`
    4) You can start the daemon with `sudo start couchdb`
    5) `sudo restart couchdb` works as expected
    6) Upstart respawn works as expected if I manually `kill $PID` on the daemon process
    7) All daemon processes are killed with `sudo apt-get remove couchdb`
    8) `sudo apt-get purge couchdb` removes /var/lib/couchdb and /var/log/couchdb

  == Upgrade Testing ==

  I tested the upgrade from 1.2.0 when only `couchdb-bin` is installed,
  and when `couchdb` and `couchdb-bin` are installed. Both work as
  expected, although these tests were done on Raring. I haven't yet done
  an upgrade test via a Raring=>Saucy update, but that's difficult to do
  when 1.4.0 is still only in a PPA (update process can't be properly
  simulated as the PPA will be disabled during the update).

  A remaining issue is that sometimes the `couchdb` 1.2.0 daemon is not
  successfully terminated during the package upgrade. (Well, it sort of
  is, and then Erlang respawns more processes that don't ever get
  killed.) So you'll end up with the new, correct 1.4.0 processes
  running, plus some lingering 1.2.0 garbage processes running. This is
  due to fundamental problems in the upstream init.d script, and this is
  a big part of why I switched to Upstart.

  A work-around is to stop couchdb before you upgrade: 
    sudo service couchdb stop

  Or simply reboot after you upgrade (which most will do anyway).

  This is probably a difficult issue to solve as the problem is that the
  previous package version isn't correctly shutting down its CouchDB
  daemon. On the upside, no such problems exist with the Upstart job in
  my 1.4.0 package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/couchdb/+bug/1212481/+subscriptions