Re: [ANNOUNCE] Michael Hall elected as CouchDB committer
Thank you all! I look forward to learning more about CouchDB and becoming increasingly involved in the Apache community. Michael Hall mhall...@gmail.com On 01/05/2017 05:45 PM, Andy Wenk wrote: > Welcome in bord :D > > All the best > > > Andy > > -- > Andy Wenk > RockIt! > > Hamburg / Germany > > GPG public key: > https://pgp.mit.edu/pks/lookup?op=get=0x4F1D0C59BC90917D > >> On 5 Jan 2017, at 23:39, Joan Touzet <woh...@apache.org> wrote: >> >> Congrats! Welcome Michael. >> >> - Original Message - >>> From: "Robert Kowalski" <robertkowal...@apache.org> >>> To: dev@couchdb.apache.org >>> Sent: Thursday, January 5, 2017 2:02:52 PM >>> Subject: [ANNOUNCE] Michael Hall elected as CouchDB committer >>> >>> Dear community, >>> >>> I am pleased to announce that the CouchDB Project Management >>> Committee >>> has elected Michael Hall as a CouchDB committer. >>> >>>Apache ID: mhall119 >>> >>>IRC nick: mhall119 >>> >>>Twitter: @mhall119 >>> >>> Committers are given a binding vote in certain project decisions, as >>> well as write access to public project infrastructure. >>> >>> This election was made in recognition of Michael's commitment to the >>> project. We mean this in the sense of being loyal to the project and >>> its interests. >>> >>> Please join me in extending a warm welcome to Michael! >>> >>> On behalf of the CouchDB PMC, >>> Robert :) >>> >
Re: Publisher account for CouchDB snap
On 12/20/2016 01:56 PM, Eli Stevens (Gmail) wrote: > On Tue, Dec 20, 2016 at 9:16 AM, Michael Hall <mhall...@gmail.com> wrote: >> On 12/19/2016 06:23 PM, Eli Stevens (Gmail) wrote: >>> - Is it possible to disable automatic updates for snaps? >> >> It's possible, I don't know the details of it though. Can you tell me >> what your concern is with leaving it on? > > The FDA requires us to produce documentation detailing the versions of > 3rd party software we use to construct our product, and attest to the > suitability of those versions for the purpose that we're using them > for. Maintaining the proper documentation gets a lot harder when the > version can get swapped out from underneath us without warning. And if > there's an actual incompatibility, that means that cancer patients > might not be able to start their course of treatment on time, which > the patients, clinical staff, and our director of customer support all > agree is undesirable. ;) > As a former employee of a cancer hospital, I would find that very undesirable as well :) I have passed this on to our internal teams to see what the best way of handling this use case would be. I'll let you know as soon as I hear something. -- Michael Hall mhall...@gmail.com
Re: Publisher account for CouchDB snap
On 12/19/2016 06:23 PM, Eli Stevens (Gmail) wrote: > On Fri, Dec 16, 2016 at 11:47 AM, Michael Hall <mhall...@gmail.com> wrote: >> You can try the snap I built, it's on >> http://people.ubuntu.com/~mhall119/snaps/ >> >> Download it and run "snap install --dangerous couchdb_2.0_amd64.snap" >> (assuming you're on Ubuntu 16.04 or later) > > I'll have some people on my team get on that as soon as we have time; > probably after the new year. > Thanks! If they have any questions or need help, I'm mhall119 in #couchdb-dev or they can email me directly. > >> There isn't a generic mechanism for the dpkg->snap migration. You could >> provide tools for that, or just recommend snaps for new installs. > > I've got several hundred systems installed in customer datacenters > that need to be upgraded headlessly (we don't typically have any > access to those customer systems, so we give them a self-contained > upgrade package with OS and our product updates that has an install > script that gets run automatically). > In that case, you could have your script run "snap install couchdb" and then copy the configuration and data files into the snap's locations > I'm more curious about things like: > > - Will it Just Work(tm) if we copy the 1.6 .couch files from our old > location in /var/lib/couchdb? I would assume so, unless there's some metadata in them that used absolute file paths to other data files. Can someone more familiar with the couchdb data files give a more definite answer? > - Can we use ecryptfs for the data dirs? (I'd assume so, but it's not > clear how they get mounted) Snaps don't know or care what filesystem those directories are. AppArmor is used to mitigate file access, so it should all be transparent to the snap. > - Is it possible to disable automatic updates for snaps? It's possible, I don't know the details of it though. Can you tell me what your concern is with leaving it on? > - Are our Ubuntu 12.04 systems ever going to see CouchDB 2.0? Snaps can run on 14.04, but that's as far back as we've been able to support, since snapd and snap-confine depend on newer kernel features and systemd. And since 12.04 is going to be EOL next year, I hope you're planning an upgrade of those systems anyway, > > I realize that some of these questions are more about snaps than > CouchDB. Sorry. :/ > Well this thread is about snaps (for couchdb) so that seems entirely appropriate :) > >> I would encourage having people test the snap in production-like >> environments for a while first. I used a very basic configuration and >> there might need to be more work done to allow it to work for all use >> cases. The Snap technology is stable enough for production use, but I'd >> like to see each individual app tested thoroughly before telling people >> to replace their existing package installs. > > Okay, it sounds like there are no known issues preventing it from > possibly being production ready. We'd certainly put the system through > the paces of our release testing process before deployment. > I'd love to hear how that goes, any feedback you can give me about using the snap I will funnel back to the snappy development team so they can improve it. Michael Hall mhall...@gmail.com
Re: Publisher account for CouchDB snap
On 12/16/2016 02:10 PM, Eli Stevens (Gmail) wrote: > Very cool. We've been wanting a packaged version of 2.0 for a while. > You can try the snap I built, it's on http://people.ubuntu.com/~mhall119/snaps/ Download it and run "snap install --dangerous couchdb_2.0_amd64.snap" (assuming you're on Ubuntu 16.04 or later) > This might be jumping the gun, but I'm curious to know what the story > is for upgrading from previous, non-snap versions is, and how > post-snap upgrades will be handled. At first glance, it seems like > there is a trade off between having to copy the entire DB per version > upgrade, or losing the ability to revert if compaction modifies the DB > in a non-backwards-compatible way. How are you handling those > situations? > There isn't a generic mechanism for the dpkg->snap migration. You could provide tools for that, or just recommend snaps for new installs. Likewise there isn't a generic mechanism for migrating and reverting data in the common (non-versioned) directory, because it would have to be app-specific. There is a new "hook" feature that could be used to run a script on install/update/revert that could then run whatever migration would be needed. > Also, would you consider the snap package to be stable enough for > production install once the logistics get sorted out, or is it still > experimental? > I would encourage having people test the snap in production-like environments for a while first. I used a very basic configuration and there might need to be more work done to allow it to work for all use cases. The Snap technology is stable enough for production use, but I'd like to see each individual app tested thoroughly before telling people to replace their existing package installs. Michael Hall mhall...@gmail.com > Thanks! > Eli > > On Fri, Dec 16, 2016 at 10:56 AM, Robert Kowalski <r...@kowalski.gd> wrote: >> Everything set up, I think we have to figure out when the next release >> happens. >> >> On Fri, Dec 16, 2016 at 2:04 PM, Robert Kowalski <r...@kowalski.gd> wrote: >>> Hi Micheal, >>> >>> thank you so much! You are doing awesome work! >>> >>> I registered an account: https://cldup.com/1cbKxu0igy.png >>> >>> Let's chat on IRC regarding the next steps, I don't know how to use >>> snap on my Mac. >>> >>> Best, >>> Robert >>> >>> >>> On Fri, Dec 16, 2016 at 3:04 AM, Michael Hall <mhall...@gmail.com> wrote: >>>> Over the past few months, with help from rnewsom, jan and others, we've >>>> been able to create a Snap[1] package for CouchDB 2.x that I would like >>>> to make available through the Snap Store. >>>> >>>> The Snap Store encourages upstreams to publish their packages >>>> themselves, rather than depending on distro developers to do so. >>>> Registering a package in the store is currently limited to individual >>>> accounts, there's no support yet for teams, which means that someone >>>> would need to register "apache-couchdb" as a developer account in the >>>> store. They can then share upload rights for the couchdb snap with other >>>> individuals, but it needs to be owned by someone to start with. >>>> >>>> On IRC there was some discussion about how to approach this, with the >>>> suggestion that someone on the PMC could register the owning account, >>>> using the ASF mailing address[2] and their own email. This should >>>> require very little work to setup, and almost no work after the initial >>>> setup. So I'm asking if anyone on the PMC would be willing to take this >>>> up and help us get the snap package published to users. >>>> >>>> [1] http://snapcraft.io >>>> [2] yes it's asked for, and I agree it shouldn't be needed >>>> >>>> -- >>>> Michael Hall >>>> mhall...@gmail.com
Publisher account for CouchDB snap
Over the past few months, with help from rnewsom, jan and others, we've been able to create a Snap[1] package for CouchDB 2.x that I would like to make available through the Snap Store. The Snap Store encourages upstreams to publish their packages themselves, rather than depending on distro developers to do so. Registering a package in the store is currently limited to individual accounts, there's no support yet for teams, which means that someone would need to register "apache-couchdb" as a developer account in the store. They can then share upload rights for the couchdb snap with other individuals, but it needs to be owned by someone to start with. On IRC there was some discussion about how to approach this, with the suggestion that someone on the PMC could register the owning account, using the ASF mailing address[2] and their own email. This should require very little work to setup, and almost no work after the initial setup. So I'm asking if anyone on the PMC would be willing to take this up and help us get the snap package published to users. [1] http://snapcraft.io [2] yes it's asked for, and I agree it shouldn't be needed -- Michael Hall mhall...@gmail.com
Re: CouchDB 2.0 as Snap
I've done a little more work on the snapcraft.yaml, and integrated it with couchdb's build files. Pull request is https://github.com/apache/couchdb/pull/442 You can now ./configure && make snap Michael Hall mhall...@gmail.com On 10/06/2016 12:57 PM, Adam Kocoloski wrote: > 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// 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 >>>>>> &g
Re: CouchDB 2.0 as Snap
Ah, yes, I had originally built and run couchdb in an LXC container, so I changed the bind address so I could access it from outside the container. Since Snaps aren't containers that isn't needed, so it can be removed from snap.ini (and overwritten in local.ini when needed) Michael Hall mhall...@gmail.com On 10/06/2016 12:57 PM, Adam Kocoloski wrote: > 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// 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 >>>>> -- >>>>> >>>>>> >>>>&
Re: CouchDB 2.0 as Snap
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// 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 >>>
Re: CouchDB 2.0 as Snap
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 >>>
Re: CouchDB 2.0 as Snap
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? 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 >>>> >>> >> >
Re: CouchDB 2.0 as Snap
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 Description: application/yaml
CouchDB 2.0 as Snap
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
