The change makes "weave expose" to call the "/expose" HTTP
endpoint implemented in router which exposes the bridge.
Such architectural change required as we need to know whether NPC is
enabled when exposing the bridge and weaver knows this fact the best.
Unfortunately, this change makes impossible to "weave expose"
when weaver is not running.
Fixes#2957
- replace `docker stop` with `weaveuitl stop-container`
- replace `docker kill` with `weaveutil kill-container`
- replace `docker rm` with `weaveutil remove-container`
- replace `docker run` with minimal `weaveutil container-run`
- replace `docker inspect -f {{.ID}}` with `weaveutil container-id`
- replace data-only container `docker create` with `weaveutil create-volume-container`
- remove `docker inspect` dependencies from `weave` script
`rewrite_etc_hosts` and `with_container_fqdn`
- rework `weave` script `check_running` and `check_not_running` to use `weaveutil`
- rework `weave version` to use `weaver` /report API or `weaver --version` if not running
- rework `weave setup`'s `docker pull` to run locally rather than in `weaveexec` container
The fix ensures that if odp is not supported (usually due to
missing openvswitch, vxlan or vport-vxlan kernel modules),
weaver will create the pcap based bridge instead of crashing.
The problem is that the plugin name is prefixed with a registry name.
So, if the plugin is fetched from Docker Store, its name will be
"store/weaveworks/net-plugin".
The detection function does an exact match on "weaveworks/net-plugin",
so in the Docker Store case, the presence of the plugin cannot be
detected.
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".
This implementation should be more efficient because it only uses the
names under /proc, whereas the previous implementation fetched the
full directory entry for each one, and sorted them too.
New behaviour in Docker 1.12 means it disregards a plugin-supplied
address pool that overlaps an existing route, which causes a hang as
noted in #2469. When we pass in the subnet, Docker believes we really
do want that address range and avoids the hang.
Martynas Pumputis