Nice work Michael! I noticed your snap.ini overrides the bind address for both the cluster port and the node-local port to have them listen on all interfaces. I think it’s worth discussing whether we want that to be the default for the snap. There’s a reason CouchDB defaults to listening only on the loopback interface. Otherwise it looks good to me.
Adam > On Oct 6, 2016, at 8:39 AM, Michael Hall <mhall...@gmail.com> wrote: > > Hey everyone, > > Sorry for the long delay, but I got some help from a coworker and > between the two of us we have fixed the issue with the systemd service. > > If you put the attached files into a directory with the couchdb > directory from ./rel/ you get after building, then run "snapcraft snap" > you will get a ~40MB couchdb_2.0_amd64.snap (or whatever arch you're on) > that, when installed with "snap install couchdb_2.0_amd64.snap > --force-dangerous" will get you a running couchdb instance on > http://localhost:5984 (see attached screenshot). The --force-dangerous > is only needed because it's a local (untrusted) file, once it's being > published into the snap store that won't be needed and user can install > it with a simple "snap install couchdb". > > It's configured to put local.ini and couchdb.log into SNAP_DATA, which > will be /var/snap/couchdb/<version>/ and the actual database files in > SNAP_COMMON which will be /var/snap/couchdb/common/. The first will be > forward-copied every time you install a new version, the second is > unversioned so you won't be duplicating large database files on upgrades. > > I'd like to get this into upstream now that it produces a working snap, > and from there it can be improved as needed based on feedback from users. > > Michael Hall > mhall...@gmail.com > > On 09/19/2016 07:36 PM, Robert Newson wrote: >> Make a separate systemd service for epmd and have the couch one depend on >> it. There is a parameter you can add to couch's vm.args file to prevent it >> even trying to start epmd. >> >> Sent from my iPhone >> >>> On 19 Sep 2016, at 22:47, Michael Hall <mhall...@gmail.com> wrote: >>> >>> Thanks to help from Jan and Wohali on IRC, I was able to manually build >>> couchdb from the 2.0.x branch, and then snap-package the resulting >>> binary. I have attached the snapcraft.yaml used for this. Put this file >>> in a directory with the couchdb directory built in ./rel/, then run >>> "snapcraft snap" to build couchdb_2.0_amd64.snap >>> >>> The snap package will create a systemd service file for running couchdb >>> as a daemon, but due to the way it launches a background epmd process >>> this isn't working right (systemd thinks it failed to start and keeps >>> trying to restart it until it givesup). Because of that, I've also >>> included a /snap/bin/couchdb.run which will manually kick it off, but >>> this should only be temporary until the daemon process can be fixed. >>> >>> One last caveat, you'll need to copy /snap/couchdb/current/etc/*.ini >>> into /var/snap/couchdb/current/ and mkdir /var/snap/couchdb/current/data >>> before running it. This could be done at runtime either by couchdb >>> itself, or with a custom wrapper script for the snap command. >>> >>> Michael Hall >>> mhall...@gmail.com >>> >>>> On 09/19/2016 01:19 PM, Jan Lehnardt wrote: >>>> >>>>> On 19 Sep 2016, at 19:13, Michael Hall <mhall...@gmail.com> wrote: >>>>> >>>>> Maybe I'm using the wrong branch, because the Makefile has an "install" >>>>> target but not a "release" target. I'm using developer-preview-2.0, if >>>>> that's not the correct one, which should I use? >>>> >>>> Please use the `2.0.x` branch. >>>> >>>> Best >>>> Jan >>>> -- >>>> >>>>> >>>>> Michael Hall >>>>> mhall...@gmail.com >>>>> >>>>>> On 09/19/2016 12:10 PM, Jan Lehnardt wrote: >>>>>> Heya, nice effort here :) >>>>>> >>>>>> CouchDB 2.0 doesn’t use autotools. It mimics them minimally, but only >>>>>> insofar as it is useful for CouchDB and not for tools that expect >>>>>> autotools-like behaviour. >>>>>> >>>>>> Over time, we want to make it so that the CouchDB install procedure >>>>>> fits right into normal tooling, but we are not there yet. >>>>>> >>>>>> Especially, `make install` is not available in 2.0. Instead, we >>>>>> have `make release` which produces a location independent directory >>>>>> `./rel/couchdb` that you can move into your system where you need it. >>>>>> >>>>>> There is no way to externalise log files or so from a setup perspective >>>>>> (although it can be configured in local.ini). >>>>>> >>>>>> HTH >>>>>> >>>>>> Best >>>>>> Jan >>>>>> -- >>>>>> >>>>>>> On 19 Sep 2016, at 17:48, Michael Hall <mhall...@gmail.com> wrote: >>>>>>> >>>>>>> I have attached the snapcraft.yaml file I've started. This is used by >>>>>>> the snapcraft tool to build and package a .snap file (just run >>>>>>> `snapcraft snap` in the same directory as this file). >>>>>>> >>>>>>> You can see that most of it is dedicated to grabbing the source, >>>>>>> specifying build dependencies (build-packages) and runtime dependencies >>>>>>> (stage-packages). The 'autotools' plugin will run the standard >>>>>>> "./configure; make; make install" steps on the source, and while the >>>>>>> output of those claims to be successful, make returns with a non-zero >>>>>>> status code ($?=2) which causes snapcraft to abort after building. >>>>>>> >>>>>>> As mentioned previously, this could be significantly simplified if it >>>>>>> could use the build processes already in place. In that case the >>>>>>> snapcraft.yaml would only need to be pointed to the local directory >>>>>>> containing the binary files needed to include in the .snap package. If >>>>>>> somebody wants to give that a try, I can put together a new >>>>>>> snapcraft.yaml that will do that. >>>>>>> >>>>>>> >>>>>>> Michael Hall >>>>>>> mhall...@gmail.com >>>>>>> >>>>>>>> On 09/19/2016 02:56 AM, Constantin Teodorescu wrote: >>>>>>>> It would be nice to have two snap packages: >>>>>>>> - CouchDB 2.0 UN-CLUSTERED >>>>>>>> - CouchDB 2.0 CLUSTERED VERSION >>>>>>>> >>>>>>>> That will encourage a lot of "standalone" CouchDB users to upgrade to >>>>>>>> a 2.0 >>>>>>>> version without the clustering overload stuff, and thus make a big >>>>>>>> pool of >>>>>>>> 2.0 testers and bug-reporters! >>>>>>>> Teo >>>>>>>> >>>>>>>> >>>>>>>>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall <mhall...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> First off, congratulations on the upcoming 2.0 release! >>>>>>>>> >>>>>>>>> I would love to see this new version available as a Snap package for >>>>>>>>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on >>>>>>>>> 1.6.0 for the next 5 years of it's lifecycle. >>>>>>>>> >>>>>>>>> Snaps are self-contained packages that include all of the dependencies >>>>>>>>> they need, which lets them run as you (the upstream) intended across >>>>>>>>> new >>>>>>>>> releases of Ubuntu, Debian, Arch, and many other distros. They run in >>>>>>>>> a >>>>>>>>> sandbox that protects them from changes made to the user's system, but >>>>>>>>> with a number of optional interfaces if you need deeper interaction or >>>>>>>>> to share data with other apps. >>>>>>>>> >>>>>>>>> Every snap includes its own file tree, and is run on top of the same >>>>>>>>> base image regardless of distro or form factor. This keeps the >>>>>>>>> application's own files isolated from other apps and the host system, >>>>>>>>> in >>>>>>>>> a read-only filesystem, which makes updating them safe and simple >>>>>>>>> while >>>>>>>>> keeping you in control of the whole stack that your application runs >>>>>>>>> on. >>>>>>>>> The snappy runtime then provides writable areas for storing both >>>>>>>>> versioned and unversioned data, as well as system-wide or per-user >>>>>>>>> data. >>>>>>>>> >>>>>>>>> We also provide a Snap Store, which combines the speed of >>>>>>>>> self-publishing with the discoverability of a central archive. It is >>>>>>>>> used by default across all Ubuntu 16.04 flavors and derivatives, and >>>>>>>>> any >>>>>>>>> distro where snaps have been enabled. Thanks to Snap's confinement, >>>>>>>>> applications can be published immediately after uploading. This means >>>>>>>>> that your application and updates are available to tens of millions of >>>>>>>>> users as soon as you press the button. >>>>>>>>> >>>>>>>>> I started the work on producing a Snap package for Couchdb 2.0, but >>>>>>>>> as I >>>>>>>>> couldn't find a binary release I had to try building it from source >>>>>>>>> and >>>>>>>>> unfortunately I was not successful on that step. I am happy to share >>>>>>>>> my >>>>>>>>> packaging configuration with anybody here who knows the build process >>>>>>>>> better than me, but it would be even simpler to create the snap >>>>>>>>> package >>>>>>>>> at the end of whatever process you already have to build binary >>>>>>>>> releases. I am happy to help with either or both approaches, and you >>>>>>>>> can >>>>>>>>> also learn more about the snap format and tools here: >>>>>>>>> http://snapcraft.io/ >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Hall >>>>>>>>> mhall...@gmail.com >>>>>>>>> >>>>>>>> >>>>>>> <snapcraft.yaml> >>>>>> >>>> >>> <snapcraft.yaml> >> > <snap.ini><snapcraft.yaml><snap_run.txt>
