local.ini sourced from tree on installation

[sklassen]

Overview

Changed the install hook to source from the tree. Subsequent upgrades will copy from previous revisions

Updated the documentation files

Testing recommendations

Built couchdb snap locally and tested fresh installation

Related Pull Requests

Makes enhancements to previous PR #37

Checklist

• Code is written and works correctly;
• Changes are covered by tests;
• Documentation reflects the changes;

[wohali]

@sklassen I'm confused. I thought we agreed that your configure hook would put its 10-<section>.ini files in etc/default.d. This still seems to be putting them in local.d. Which is it?

[sklassen]

I thought we agreed that your configure hook would put its 10-<section>.ini files in etc/default.d. This still seems to be putting them in local.d. Which is it?

snapcraft.yaml is writing to /snap/couchdb/current/rel/couchdb/etc/default.d once and only with one file couchdb.ini and only specifying the data and index directory which is specific to a ubuntu snap installation. For this reason /etc/default.d is mounted read-only.

the install and config hooks are user-generated changes and sit in /var/snap/couchdb/current/etc/local.d on the writtable /var mount

/snap/couchdb/current/rel/couchdb/etc/default.ini and /var/snap/couchdb/current/etc/local.ini are both per usually, but the former read-only and the latter writable.

I think this is consistent with the /snap/couchdb/current/rel/couchdb/etc/default.d/README. "snap set" are user changes and should be in local.d.

I'll add a number to default.d/couchdb.ini so that it looks like local.d

Another perspective is that 'snap set' is a configuration tool (just like puppet, chef, ansible, or salt) and so should be in local.d

[sklassen]

@wohali , If you're uncomfortable with the 'snap set' for couchdb configuration files then I can remove it. (I will leave 'snap set' for vm.args). CouchDB configure can be modified manually or via HTTP configure.

[wohali]

Hi @sklassen , sorry I haven't had time to look at this. I'm moving into 2.3.0 release activities and don't have much time free for other issues. I am going to do my best to get this sorted and merged before then, but I'm still not 100% sure I want to promote a snap as an official thing for 2.3.0 - more likely it'll be a beta channel snap until we're sure we have all the issues ironed out.

The soonest I'll be able to look at this ticket again is Saturday. Sorry about that.

[sklassen]

No trouble at all. It's your call if you want the 'snap set' ability for couchdb.ini files in or out. Having done the work, I'm biased to remove it for couchdb.ini but leave it for vm.args. The current subset of couchdb parameters that are settable is not exhaustive -- and to do so would be exhausting -- as such, having some configurable and not others might only add confusion. In most cases, the HTTP configure suffices.

…

On Fri, Nov 16, 2018 at 3:32 AM Joan Touzet ***@***.***> wrote: Hi @sklassen <https://github.com/sklassen> , sorry I haven't had time to look at this. I'm moving into 2.3.0 release activities and don't have much time free for other issues. I am going to do my best to get this sorted and merged before then, but I'm still not 100% sure I want to promote a snap as an official thing for 2.3.0 - more likely it'll be a beta channel snap until we're sure we have all the issues ironed out. The soonest I'll be able to look at this ticket again is Saturday. Sorry about that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGrF5W7lgN6fOiSkOfIq5qSqWAiYftMIks5uvcExgaJpZM4YTD68> .

[wohali]

@sklassen Let's do that then - that mirrors the Docker approach more closely.

[sklassen]

Okay, that's now done. Far simpler configure hook now.

[wohali]

@sklassen FYI see apache/couchdb-docker#117 - we discussed this previously - may be a better way forward for the snap.

I'll merge this now, but you should consider updating this.

We are about to release CouchDB 2.3.0 - once the other builds are done (packages, Docker, Windows, Mac) I will turn my attention back to this issue. If you've got a PR up by then (probably in 10 days or so) to just install from our .deb file, that'd be fantastic - will save a ton of work, keep the snapfile definition fairly static across releases, and would make me much more comfortable moving future snap releases into the stable category on the snap store.

[sklassen]

@wohali On the last PR, I have built a new snap using the master copy and have push the files to the ubuntu store with both 2.2 (stable) and 2.3 (candidate) `snap install couchdb-sklassen` installs the 2.2 version; `snap refresh --candidate couchdb-sklassen` rolls forward to 2.3 and then, if needed, `snap revert couchdb-sklassen` rolls back. So the new package, builds, installs and rolls forward and back. I'd like feed back if this is working for others. As for your second part, I've also built a new snapcraft.yaml file that uses the debian package. https://github.com/sklassen/couchdb-pkg branch snap_deb_src The BUILD.md has the steps I took. You basically install couchdb on the base system and then copy the couchdb directory to the /snap install directory. It seems to work for me, although I haven't tested it extensively. I only got it to run on 16:04 (couchjs moz lib package issue) with 2.2. It is not at a stage I'd raise a PR for it. Because it copies files from the base system, which is not how the snapcraft is meant to be, and might be disallowed in the future, it's not pretty. Currently, there is no way to add sources during the build stage, although future snapcraft versions might fix this. For the moment, I'm left just coping it from the base system. It would be easier if I could just install apt-get couchdb from within the snap, but that you require couchdb .deb package being in the official package. You can see from the yaml file how I copy across the /opt/couchdb and how the snap_run file and hooks link back to the /snap and the /var/snap directories. For my part, I still prefer building from git or tar. It gives more flexibility and doesn't create a dependency on the deb file. And, further, it is compliant with the current snapcraft guidelines. Still, if you like this method better, you could try it against your base system for 2.3. Cheers Simon

…

On Fri, Nov 30, 2018 at 3:28 PM Joan Touzet ***@***.***> wrote: @sklassen <https://github.com/sklassen> FYI see apache/couchdb-docker#117 <apache/couchdb-docker#117> - we discussed this previously - may be a better way forward for the snap. I'll merge this now, but you should consider updating this. We are about to release CouchDB 2.3.0 - once the other builds are done (packages, Docker, Windows, Mac) I will turn my attention back to this issue. If you've got a PR up by then (probably in 10 days or so) to just install from our .deb file, that'd be fantastic - will save a ton of work, keep the snapfile definition fairly static across releases, and would make me much more comfortable moving future snap releases into the stable category on the snap store. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGrF5Wl9fcGW9wQ2VhxRwx6bYvxu61-Hks5u0N4pgaJpZM4YTD68> .