You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2018/11/05 17:29:59 UTC
[GitHub] wohali commented on a change in pull request #37: New Instructions
for installing snap including enabling interfaces
wohali commented on a change in pull request #37: New Instructions for installing snap including enabling interfaces
URL: https://github.com/apache/couchdb-pkg/pull/37#discussion_r230840834
##########
File path: snap/HOWTO.md
##########
@@ -1,109 +1,108 @@
# HOW TO install a cluster using snap
-# Create three machines
+## Create three nodes
-In the instruction below, we are going to set up a three -- the miniumn number needed to gain performace improvement -- Couch cluster database. In this potted example we will be using LXD.
+In the example below, we are going to set up a three node CouchDB cluster. (Three is the minimum number needed to support clustering features.) We'll also set up a separate, single machine for making backups. In this example we will be using LXD.
-We launch a new container and install couchdb on one machine
+We launch a (single) new container, install couchdb via snap from the store and enable interfaces.
-1. localhost> `lxc launch ubuntu:18.04 couchdb-c1`
-1. localhost> `lxc exec couchdb-c1 bash`
-1. couchdb-c1> `apt update`
-1. couchdb-c1> `snap install couchdb`
-1. couchdb-c1> `logout`
-
-Here we use LXD copy function to speed up the test
+```bash
+ 1. localhost> lxc launch ubuntu:18.04 couchdb-c1
+ 1. localhost> lxc exec couchdb-c1 bash
+ 1. couchdb-c1> apt update
+ 1. couchdb-c1> snap install couchdb
+ 1. couchdb-c1> snap connect couchdb:mount-observe
+ 1. couchdb-c1> snap connect couchdb:process-control
+ 1. couchdb-c1> logout
```
-lxc copy couchdb-c1 couchdb-c2
-lxc copy couchdb-c1 couchdb-c3
-lxc copy couchdb-c1 cdb-backup
-lxc start couchdb-c2
-lxc start couchdb-c3
-lxc start cdb-backup
+
+Back on localhost, we can then use the LXD copy function to speed up installation:
+```bash
+ $ lxc copy couchdb-c1 couchdb-c2
+ $ lxc copy couchdb-c1 couchdb-c3
+ $ lxc copy couchdb-c1 cdb-backup
+ $ lxc start couchdb-c2
+ $ lxc start couchdb-c3
+ $ lxc start cdb-backup
```
+## Configure CouchDB using the snap tool
-# Configure CouchDB (using the snap tool)
+We are going to need the IP addresses:
-We are going to need the IP addresses. You can find them here.
-```
-lxc list
+```bash
+ $ lxc list
```
-Now lets use the snap configuration tool to set the configuration files.
-```
-lxc exec couchdb-c1 snap set couchdb name=couchdb@10.210.199.199 setcookie=monster admin=password bind-address=0.0.0.0
-lxc exec couchdb-c2 snap set couchdb name=couchdb@10.210.199.254 setcookie=monster admin=password bind-address=0.0.0.0
-lxc exec couchdb-c3 snap set couchdb name=couchdb@10.210.199.24 setcookie=monster admin=password bind-address=0.0.0.0
-```
-The backup machine we will leave as a single instance and no sharding.
-```
-lxc exec cdb-backup snap set couchdb name=couchdb@127.0.0.1 setcookie=monster admin=password bind-address=0.0.0.0 n=1 q=1
+Now, again from localhost, and using the `lxc exec` commond, we will use the snap configuration tool to set the various configuration files.
+```bash
+ $ lxc exec couchdb-c1 snap set couchdb name=couchdb@10.210.199.199 setcookie=monster admin=Be1stDB bind-address=0.0.0.0
+ $ lxc exec couchdb-c2 snap set couchdb name=couchdb@10.210.199.254 setcookie=monster admin=Be1stDB bind-address=0.0.0.0
+ $ lxc exec couchdb-c3 snap set couchdb name=couchdb@10.210.199.24 setcookie=monster admin=Be1stDB bind-address=0.0.0.0
```
+The backup machine we will leave as a single instance.
-The snap must be restarted for the new configurations to take affect.
-```
-lxc exec couchdb-c1 snap restart couchdb
-lxc exec couchdb-c2 snap restart couchdb
-lxc exec couchdb-c3 snap restart couchdb
-lxc exec cdb-backup snap restart couchdb
+ $ `lxc exec cdb-backup snap set couchdb name=couchdb@127.0.0.1 setcookie=monster admin=Be1stDB bind-address=0.0.0.0 n=1 q=1`
+
+Each snap must be restarted for the new configurations to take affect.
+```bash
+ $ lxc exec couchdb-c1 snap restart couchdb
+ $ lxc exec couchdb-c2 snap restart couchdb
+ $ lxc exec couchdb-c3 snap restart couchdb
+ $ lxc exec cdb-backup snap restart couchdb
```
The configuration files are stored here.
-```
-lxc exec cdb-backup cat /var/snap/couchdb/current/etc/vm.args
-lxc exec cdb-backup cat /var/snap/couchdb/current/etc/local.d/*
+```bash
+ $ lxc exec cdb-backup cat /var/snap/couchdb/current/etc/vm.args
+ $ lxc exec cdb-backup cat /var/snap/couchdb/current/etc/local.d/*
```
Any changes to couchdb from the http configutation tool are made here
+```bash
+ $ lxc exec cdb-backup cat /var/snap/couchdb/current/etc/local.d/local.ini
Review comment:
This isn't true. In fact, [in your current setup, they will probably end up at `etc/local.ini`](https://github.com/apache/couchdb-pkg/blob/master/snap/snap_run#L19). Try: `curl -X PUT $HOST/_node/_local/_config/ssl/port -d '"9999"'` and see where the new setting ends up.
https://github.com/apache/couchdb-pkg/blob/master/snap/meta/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.
Per your `configure` hook, this could be any one of:
```
local.d/native_query_servers.ini
local.d/couch_peruser.ini
local.d/uuids.ini
local.d/log.ini
local.d/couchdb.ini
local.d/compaction_daemon.ini
local.d/cluster.ini
local.d/chttpd.ini
local.d/httpd.ini
local.d/ssl.ini
local.d/admins.ini
```
It'll be whichever alphabetically sorts last.
Worse, if these changes eclipse changes made at the command line, people will get confused.
In other distributions, such as our debian/ubuntu packages, we use this approach:
* `default.ini`: the actual default from `couchdb`, unchanged
* `default.d/*.ini`: any changes we impose specific to the packaging that may change in newer packages, but are specific to the package we release. For you, you should place this https://github.com/apache/couchdb-pkg/blob/master/snap/couchdb.ini file into the `default.d` directory since this is invariant and specific to snap packaging. Over in the main Debian/Ubuntu/CentOS/RedHat packages, we use `default.d/10-filelog.ini` to log to a file, not to stdout by default, as was requested by our users. (https://github.com/apache/couchdb-pkg/search?q=10-filelog.ini&unscoped_q=10-filelog.ini) Unfortunately, you don't allow for use of the `default.d` directory in your re-ordered approach, you've left it out of the CLI parameters. This is a mistake.
* `local.ini`: many users make all of their changes in this file directly. In a system where they are using a configuration management tool (puppet, chef, ansible, salt) this is extremely common.
* `local.d/*.ini`: Changes in this directory necessarily eclipse changes to `local.ini` in the default configuration. In your changes, you've reversed these. Bad idea, especially because it will confuse users who read our documentation and expect CouchDB to act the same.
**In short: move all of your snap-created `*.ini` files into `etc/default.d`, remove your [`ERL_FLAGS`](https://github.com/apache/couchdb-pkg/blob/master/snap/snap_run#L19) override, and you'll get the behaviour you're looking for, I think.**
With this change:
1. any HTTP API-based config changes will be in `etc/local.ini` as expected, unless the end user decides to start adding files under `local.d`, in which case they'll go to the very last file alphabetically in that directory.
1. any changes made by snap will end up under `default.d/*.ini`, where if necessary they can be eclipsed by changes via the normal CouchDB HTTP API.
1. With the `ERL_FLAGS` removed, your snap operates exactly as we document it over at the official CouchDB documentation.
The only other concern is whether any settings in `local.ini` as we ship it would eclipse your snap-imposed settings that (now go into) `default.d/*.ini`. I think that's OK personally.
----------------------------------------------------------------
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:
users@infra.apache.org
With regards,
Apache Git Services