Docker Plugin V2 does not expose a plugin name to the plugin, so we
check for "net-plugin" within driver name of a network to detect
whether network is ours.
- "noDNS" controls whether upon ContainerStarted event a container
should be registered within the Weave DNS.
- "isPluginV2" will be used to determine a path to host's /proc.
Renamed to "is_plugin_v1_enabled" and "is_plugin_v2_enabled".
Improve weave status and weave launch* err message when plugin-v2 is running
```
$ weave launch
Docker plugin "weaveworks/net-plugin" is running; Aborting.
$ weave status
<..>
Service: plugin (v2)
DriverName: weaveworks/net-plugin
```
"docker plugin" does not support tagging plugin images, therefore
we need to build plugin images two times - one for :latest and
for :$(WEAVE_VERSION).
Pushing of :latest happens only if $UPDATE_LATEST is not false.
For example:
```
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker plugin ls
ID NAME DESCRIPTION ENABLED
e80beb4367a6 weaveworks/pluginv2:latest Weave Net plugin for Docker true
$ weave --local launch
weaveworks/pluginv2 is already running.
$ weave --local launch-proxy
weaveworks/pluginv2 is already running.
$ weave --local launch-router
weaveworks/pluginv2 is already running.
$ weave --local launch-plugin
```
NetworkAllocate is called on Swarm master node which creates a network.
The return option map is used to describe the network, and is passed
to CreateNetwork which is called on all nodes when a service is
created.
Returning nil instead the actual options made Docker to omit
the "works.weave.multicast" flag, thus no multicast could be used
in Swarm.
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".
Bryan Boreham