`weaveexec` no longer mounting '/' so we can't access the weavedb file
to get persistent peer ID. If `weaver` was running, we couldn't have
read the file anyway because BoltDB does not support concurrent access
from two processes.
Consequence is that if someone really does need the bridge creation on
'weave expose' the peer ID may change if created pre-1.9.0. We'll just
live with that (per @bboreham).
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
Otherwise, the plugin is not able to load kernel modules
(openvswitch, vxlan, vport_vxlan) required by fastdp which
makes weave to fallback to sleeve.
CAP_SYS_MODULE is required in order to load kernel modules.
- "You cannot call `weave rmpeer` on more than one host" - yes you
can, but you must not call it on more than one host *for the same
peer*
- `weave forget` has nothing to do with this
- "results in duplicate IPs" - no, it causes duplicate address range
assignments
- "the address is reassigned" - it's the address *range* that is
reassigned
- "claim" is a new and confusing term -> drop
- "address space" -> "address range" (that's what it's called
elsewhere)
David Shepherd