This simplifies the following:
- plugin-v2 does not need to start "plugin" as a separate process, thus
Docker is able to properly restart plugin-v2 in a case of any child
process failing.
- No need for weaveplugin container.
plugin is enabled by default when running "weave launch". when starting
only the router, you should pass "--plugin" parameter to enable it.
The env var WEAVE_NO_PLUGIN is no more.
Since 1.12.0, `docker inspect -f "{{ .NetworkSettings.Networks.<network>.Aliases }}"` also returns the container's short ID.
See also: https://github.com/docker/docker/blob/master/CHANGELOG.md
> 1.12.0 (2016-07-28)
> Networking
> Add container's short-id as default network alias #21901
Upgrading `docker/docker-py` to 1.9.0-rc2 effectively relaxes test assertions for:
- `tests/integration/network_test.py#test_connect_with_aliases`
- `tests/integration/network_test.py#test_create_with_aliases`
which do something equivalent to:
```
$ docker network create net1
$ docker run --name c1 -d busybox top
$ docker network connect --alias foo --alias bar net1 c1
$ docker inspect -f "{{ .NetworkSettings.Networks.net1.Aliases }}" c1
[foo bar e52bf50e5ee7]
```
allowing us to be consistent with the above change.
In 1.8.1, the below fails as the container's short ID would be present:
```
self.assertEqual(
container_data['NetworkSettings']['Networks'][net_name]['Aliases'],
['foo', 'bar'])
```
In 1.9.0-rc2, the below passes as the container's short ID is ignored:
```
aliases = (
container_data['NetworkSettings']['Networks'][net_name]['Aliases']
)
assert 'foo' in aliases
assert 'bar' in aliases
```
The vars can be customized before enabling the plugin with e.g.:
docker plugin set $PLUGIN_NAME set WEAVE_MTU=8160
The ARP settings apply to "weave" bridge. In order to manipulate them,
we bind mount the host's /proc to /host/proc.
(The mount type of /proc changed to bind, Otherwise (when type =
"proc"), the kernel does not propagate pids of host processes as the
plugin runs in a separate PID ns.)
Persistence relies on weave.db which is stored under
/var/lib/weave/weave.db on the host.
NOTE: we do not persist peer list for plugin-v2, as it gets
restored from existing alive master nodes during the peer discovery.
The peer discovery relies on "GET /info" API call which returns
list of master nodes. The peer list is passed to weaver when
launching it.
If node is a master, then we pass "--ipalloc-alloc
consensus=$(MASTER_NODES_COUNT)" to weaver. Otherwise, we pass
"--ipalloc-alloc observer".
Martynas Pumputis