`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
There are 3 ways to get help:
• weave --help
• weave help
• weave <command> --help
At the moment, only the first one prints the usage instantaneously, the
others go much further in the script and take quite some time, which is
not idea of impatient users.
Note that "help" only works because it's not a recognized command and
ends up in the default case of "case $COMMAND" (and indeed, "Unknown
weave command 'help'" is displayed). This is because handle_help_arg()
always returns true and so the second part of:
handle_help_arg "$1" || handle_help_arg "--$1"
is never evaluated.
This commit changes things a bit so all 3 ways to get help are
recognized early, print the usage and exit.
`proxy_parse_args` is currently called:
- once, all the time
- again, if Docker is configured with TLS.
If a second call to `proxy_parse_args` happens, given the way we append to `PROXY_ARGS` and merge proxy and remaining args, genuine arguments like peers can be mixed with flags/options/etc. hence forming an invalid peers list and crashing Weave Net.
EmptyDir has the same lifetime as the pod, whereas we want our
persistence to extend past that, e.g. when Weave Net is upgraded.
`weave reset` cleans out the file.
We assume that /var/lib is writable.
Since it is only called in contexts where we have already checked that.
We don't need the detail of whether plugin is enabled; if it's not
running then it's ok to remove those socket files.
If the plugin wasn't enabled then that network shouldn't exist.
If the network 'weave' doesn't exist then util_op remove-plugin-network will do nothing.
If it does exist for some reason then docker will pause for a while and remove it anyway.
For some reason the previous version was de-newlined by the shell and
the new version isn't. Since I can't figure out the exact reason the
shell is now behaving differently (man page says it depends on the
quoting that is in effect) I brute-force it with 'tr'.
The standard case for --local is when the weave script in the weaveexec container
is run by the weave script, which has just checked the version.
--local is also used from weave-kube where we don't mount the docker socket and
therefore cannot check.
Since --local is undocumented we will not worry about any other cases; the worst
that can happen is a confusing error message.
Weave Net initially had the ability to start a single component at a time with `launch-proxy` and `launch-router`.
This change enables this again via `--proxy=false` despite the merge of the proxy and the router.
Note that by default:
- `launch` passes `--proxy` which enables the proxy and keeps behaviour consistent with `launch` pre-merge,
- `weaver` defaults `--proxy` to `false` which disables the proxy and keeps behaviour consistent with `weaver` pre-merge (as it was `weaveproxy`'s responsibility).
Given `proxy` & `router` processes have been merged, `launch-proxy`,
`launch-router`, `stop-proxy`, `stop-router` do not make sense any more, and
should just be `launch` and `stop` with the appropriate flags.
Note: we no longer need to detect awsvpc when launching.
The "AWS VPC" mode is now set via the `--awsvpc` flag.
Before we had to "detect" it when the proxy was potentially started
later, after the router had started.
We drop WEAVEPROXY_DOCKER_ARGS as obsolete.
Matthias Radestock