sklassen commented on issue #37: New Instructions for installing snap including enabling interfaces URL: https://github.com/apache/couchdb-pkg/pull/37#issuecomment-436020391 > @sklassen please add the snap permissions steps to your `HOWTO.md` file. Once that is done I can merge this. This should be there already (line 14 in the new file) in correct order. > FYI I will be publishing the 2.2.0 snap as an `edge` release only, does that require changing the snap installation command you provide under `README.md`? If so, please update that as well. Sure, added to README and HOWTO. > One more change: > > In this line: https://github.com/apache/couchdb-pkg/blob/master/snap/snap_run#L19 > > you change the order of ini file handling so that setting snap configurations persists correctly. You need to tell end users that you've changed CouchDB's config processing behaviour, otherwise the snap will not behave the same as we document here: http://docs.couchdb.org/en/stable/config/intro.html#configuration-files > > Please include a warning about this in `/README.md`. I had a description of the configuration order, and I thought that the more familiar HTTP should supersede the new and less known snap set. But I have no fixed opinion. I can reverse it back. /etc/local.ini and then /etc/local.d/ and make that clear in the README.md I can move the couchdb.ini with the data directory into default.ini > Any changes to couchdb from the http configutation tool are made here /etc/local.d/local.ini was a typo: it should, of course, have been /etc/local.ini > hooks/configure is a mess. You're creating a huge number of .ini files here. When any changes are made via the http interface (via /_node/_local/_config) these changes will end up in the last file in the config chain. Which may have been my idea of leave local.ini last in the list, if that is the file chosen by the http config writer. I can added sequence numbers if that turns out to be the case. My original idea was to code hook/configure so that it only changed vm.args and those items that had not been whitelisted for http configure, plus a few useful items. But the list of blacklists was long; while what I thought as useful kept growing. And I do need one file per section otherwise the bash script becomes too complicated (I tried to limit it to sed and not awk). But I'm happy to cut it back to the bare essentials and give some more examples of using HTTP configure for the other. HTTP configure does have the advantage of not requiring a restart. Do you have an opinion on which items to keep or numbers to order the configuration? > Debian/Ubuntu/CentOS/RedHat packages, we use default.d/10-filelog.ini to log to a file, not to stdout by default, That might make sense when dealing with so many distributions. But here I think the snap should default to stdout and picked up by journald. snap startup and config changes are already closely tied into the journald and if you are using ubuntu to host a cluster of couchdb, then the centralized monitoring via journactl across hosts is useful. It also writes in binary for added performance. I also wanted to avoid writting to /var/snap/couchdb/common/log as this will overwrite between instances; and also avoid writting in each /var/snap/couchdb/xx/log because then large log files after upgrade may never be rotated. journalctl handles both problems nicely. There's quite a few changes. I've started, but leave some for tomorrow and test against a fresh installation. I'll revert soon.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
