couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hall <>
Subject Re: CouchDB 2.0 as Snap
Date Thu, 06 Oct 2016 12:39:09 GMT
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

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 <> 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/ 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
>>> On 09/19/2016 01:19 PM, Jan Lehnardt wrote:
>>>> On 19 Sep 2016, at 19:13, Michael Hall <> 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
>>>>> 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 <>
>>>>>> I have attached the snapcraft.yaml file I've started. This is used
>>>>>> 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
>>>>>> 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
>>>>>> 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.
>>>>>> somebody wants to give that a try, I can put together a new
>>>>>> snapcraft.yaml that will do that.
>>>>>> Michael Hall
>>>>>>> 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 <>
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> releases. I am happy to help with either or both approaches,
and you can
>>>>>>>> also learn more about the snap format and tools here:
>>>>>>>> --
>>>>>>>> Michael Hall
>>>>>> <snapcraft.yaml>
>> <snapcraft.yaml>

View raw message