Update docs and smoke-tests with new option names

bin/multiweave

@@ -30,7 +30,7 @@ case "$1" in
     launch)
         shift 1
         for i in $(seq $START $FINISH); do
-            WEAVE_CONTAINER_NAME=weave$i WEAVE_PORT=$((5000+i)) $weavedir/weave launch-router -iface '' -name $(random_mac) -nickname weave$i -port $PORT "$@"
+            WEAVE_CONTAINER_NAME=weave$i WEAVE_PORT=$((5000+i)) $weavedir/weave launch-router --iface '' --name $(random_mac) --nickname weave$i --port $PORT "$@"
         done
         if [ $START -ne 1 ] ; then
             status=$(docker inspect --format='{{.State.Running}} {{.NetworkSettings.IPAddress}}' weave$((START-1)))

docs/dockerless.txt

@@ -125,8 +125,8 @@ VM2> nc 192.168.122.2 6783
 If all is well, you should now be able to launch weave on VM1
 then on VM2:
 
-VM1> weaver -iface veth6 -name vm1
-VM2> weaver -iface veth6 -name vm2 192.168.122.2
+VM1> weaver --iface veth6 --name vm1
+VM2> weaver --iface veth6 --name vm2 192.168.122.2
 
 Once the connection is up and running, you should be able to connect
 from VM1/ns2 to VM2/ns2 and vice versa:

site/features.md

@@ -142,9 +142,9 @@ To accomplish that, we assign each application a different subnet.
 Let's begin by configuring weave's allocator to manage multiple
 subnets:
 
-    host1$ weave launch -iprange 10.2.0.0/16 -ipsubnet 10.2.1.0/24
+    host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24
     host1$ eval $(weave env)
-    host2$ weave launch -iprange 10.2.0.0/16 -ipsubnet 10.2.1.0/24 $HOST1
+    host2$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.1.0/24 $HOST1
     host2$ eval $(weave env)
 
 This delegates the entire 10.2.0.0/16 subnet to weave, and instructs
@@ -251,10 +251,10 @@ invocation:
 ### <a name="security"></a>Security
 
 In order to connect containers across untrusted networks, weave peers
-can be told to encrypt traffic by supplying a `-password` option or
+can be told to encrypt traffic by supplying a `--password` option or
 `WEAVE_PASSWORD` environment variable when launching weave, e.g.
 
-    host1$ weave launch -password wEaVe
+    host1$ weave launch --password wEaVe
 
 or
 
@@ -496,9 +496,9 @@ and the new hosts will be added, when one runs
     host# weave connect --replace $NEW_HOST1 $NEW_HOST2
 
 For complete control over the peer topology, automatic discovery can
-be disabled with the `-nodiscovery` option to `weave launch`. In this
-mode, weave will only connect to the addresses specified at launch
-time and with `weave connect`.
+be disabled with the `--no-discovery` option to `weave launch`. In
+this mode, weave will only connect to the addresses specified at
+launch time and with `weave connect`.
 
 ### <a name="container-mobility"></a>Container mobility
 

site/ipam.md

@@ -26,8 +26,8 @@ in the whole network, weave needs a majority of peers to be present in
 order to avoid formation of isolated groups, which could lead to
 inconsistency, i.e. the same IP address being allocated to two
 different containers. Therefore, you must either supply the list of
-all peers in the network to `weave launch` or add the `-initpeercount`
-flag to specify how many peers there will be.
+all peers in the network to `weave launch` or add the
+`--init-peer-count` flag to specify how many peers there will be.
 
 To illustrate, suppose you have three hosts, accessible to each other
 as `$HOST1`, `$HOST2` and `$HOST3`. You can start weave on those three
@@ -42,13 +42,13 @@ hosts with these three commands:
 Or, if it is not convenient to name all the other hosts at launch
 time, you can give the number of peers like this:
 
-    host1$ weave launch -initpeercount 3
+    host1$ weave launch --init-peer-count 3
 
-    host2$ weave launch -initpeercount 3 $HOST3
+    host2$ weave launch --init-peer-count 3 $HOST3
 
-    host3$ weave launch -initpeercount 3 $HOST2
+    host3$ weave launch --init-peer-count 3 $HOST2
 
-### More on `-initpeercount`
+### More on `--init-peer-count`
 
 TL;DR: it isn't a problem to over-estimate by a bit, but if you supply
 a number that is too small then multiple independent groups may form.
@@ -88,9 +88,9 @@ would be safe wrt weave's startup quorum:
 ## <a name="range"></a>Choosing an allocation range
 
 By default, weave will allocate IP addresses in the 10.32.0.0/12
-range. This can be overridden with the `-iprange` option, e.g.
+range. This can be overridden with the `--ipalloc-range` option, e.g.
 
-    host1$ weave launch -iprange 10.2.0.0/16
+    host1$ weave launch --ipalloc-range 10.2.0.0/16
 
 and must be the same on every host.
 
@@ -135,13 +135,13 @@ for instance:
 When working with multiple subnets in this way, it is usually
 desirable to constrain the default subnet - i.e. the one chosen by the
 allocator when no subnet is supplied - so that it does not overlap
-with others. One can specify that with `-ipsubnet`:
+with others. One can specify that with `--ipalloc-default-subnet`:
 
-    host1$ weave launch -iprange 10.2.0.0/16 -ipsubnet 10.2.3.0/24
+    host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.3.0/24
 
-`-iprange` should cover the entire range that you will ever use for
-allocation, and `-ipsubnet` is the subnet that will be used when you
-don't explicitly specify one.
+`--ipalloc-range` should cover the entire range that you will ever use
+for allocation, and `--ipalloc-default-subnet` is the subnet that will
+be used when you don't explicitly specify one.
 
 When specifying addresses, the default subnet can be denoted
 symbolically with `net:default`.
@@ -151,10 +151,10 @@ symbolically with `net:default`.
 If you want to start containers with a mixture of
 automatically-allocated addresses and manually-chosen addresses, *and
 have the containers communicate with each other*, you can choose a
-`-iprange` that is smaller than `-ipsubnet`, For example, if you
-launch weave with:
+`--ipalloc-range` that is smaller than `--ip-default-subnet`, For
+example, if you launch weave with:
 
-    host1$ weave launch -iprange 10.9.0.0/17 -ipsubnet 10.9.0.0/16
+    host1$ weave launch --ipalloc-range 10.9.0.0/17 --ipalloc-default-subnet 10.9.0.0/16
 
 then you can run all containers in the 10.9.0.0/16 subnet, with
 automatic allocation using the lower half, leaving the upper half free
@@ -213,8 +213,8 @@ The first section covers the router; see the [troubleshooting
 guide](troubleshooting.html#status-report) for full details.
 
 The 'Allocator' section, which is only present if weave has been
-started with the `-iprange` option, summarises the overall position and
-lists which address ranges have been assigned to which peer. Each
-range begins at the address shown and ends just before the next
-address, or wraps around at the end of the subnet. The 'v' number
+started with the `--ipalloc-range` option, summarises the overall
+position and lists which address ranges have been assigned to which
+peer. Each range begins at the address shown and ends just before the
+next address, or wraps around at the end of the subnet. The 'v' number
 denotes how many times that entry has been updated.

site/proxy.md

@@ -140,8 +140,8 @@ TLS-related command-line flags as supplied to the docker daemon. For
 example, if you have generated your certificates and keys into the
 docker host's `/tls` directory, we can launch the proxy with:
 
-    host1$ weave launch-proxy --tlsverify --tlscacert=/tls/ca.pem \
-             --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem
+    host1$ weave launch-proxy --tls-verify --tls-cacert=/tls/ca.pem \
+             --tls-cert=/tls/server-cert.pem --tls-key=/tls/server-key.pem
 
 The paths to your certificates and key must be provided as absolute
 paths which exist on the docker host.
@@ -157,8 +157,8 @@ for an example.
 With the proxy running over TLS, we can configure our regular docker
 client to use TLS on a per-invocation basis with
 
-    $ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem \
-         --tlskey=key.pem -H=tcp://host1:12375 version
+    $ docker --tls-verify --tls-cacert=ca.pem --tls-cert=cert.pem \
+         --tls-key=key.pem -H=tcp://host1:12375 version
     ...
 
 or,

site/troubleshooting.md

@@ -22,8 +22,8 @@ A reasonable amount of information, and all errors, get logged there.
 
 The log verbosity can be increased by supplying the
 `--log-level=debug` option when launching weave. To log information on
-a per-packet basis use `-pktdebug` - be warned, this can produce a lot
-of output.
+a per-packet basis use `--pktdebug` - be warned, this can produce a
+lot of output.
 
 Another useful debugging technique is to attach standard packet
 capture and analysis tools, such as tcpdump and wireshark, to the
@@ -96,7 +96,7 @@ The 'Our name' line identifies the local weave router as a peer in the
 weave network, displaying the peer name followed by the peer's nickname
 in parenthesis. The nickname defaults to the name of the host on which
 the weave container was launched; if desired it can be overriden by
-supplying the `-nickname` argument to `weave launch`.
+supplying the `--nickname` argument to `weave launch`.
 
 The 'Sniffing traffic' line shows details of the virtual ethernet
 interface that weave is using to receive packets on the local

test/100_cross_hosts_test.sh

@@ -10,8 +10,8 @@ SUBNET_2=10.2.3.0/24
 
 start_suite "Ping over cross-host weave network (with and without IPAM)"
 
-weave_on $HOST1 launch -iprange $UNIVERSE -ipsubnet $SUBNET_1
-weave_on $HOST2 launch -iprange $UNIVERSE -ipsubnet $SUBNET_1 $HOST1
+weave_on $HOST1 launch --ipalloc-range $UNIVERSE --ipalloc-default-subnet $SUBNET_1
+weave_on $HOST2 launch --ipalloc-range $UNIVERSE --ipalloc-default-subnet $SUBNET_1 $HOST1
 
 start_container $HOST1    $C1/24     --name=c1
 start_container $HOST2 ip:$C2/24     --name=c2

test/110_encryption_test.sh

@@ -7,8 +7,8 @@ C2=10.2.1.7
 
 start_suite "Ping over encrypted cross-host weave network"
 
-weave_on $HOST1 launch -password notverysecure
-weave_on $HOST2 launch -password notverysecure $HOST1
+weave_on $HOST1 launch --password notverysecure
+weave_on $HOST2 launch --password notverysecure $HOST1
 
 start_container $HOST1 $C1/24 --name=c1
 start_container $HOST2 $C2/24 --name=c2

test/130_expose_test.sh

@@ -40,7 +40,7 @@ run_on1   "  $PING $EXP"
 weave_on1 "hide    $EXP/24"
 run_on1   "! $PING $EXP"
 
-weave_on $HOST1 launch -iprange $UNIVERSE
+weave_on $HOST1 launch --ipalloc-range $UNIVERSE
 
 start_container $HOST1 $C1/24 --name=c1
 start_container $HOST1 $C2/24 --name=c2

test/140_weave_local_test.sh

@@ -6,7 +6,7 @@ start_suite "Run weave with --local"
 
 run_on $HOST1 sudo weave --local reset
 
-run_on $HOST1 sudo weave --local launch -iprange 10.2.5.0/24
+run_on $HOST1 sudo weave --local launch --ipalloc-range 10.2.5.0/24
 assert_raises "docker_on $HOST1 ps | grep weave"
 
 run_on $HOST1 sudo weave --local run 10.2.6.5/24 -ti --name=c1 $SMALL_IMAGE /bin/sh

test/210_dns_multicast_test.sh

@@ -29,8 +29,8 @@ check() {
 
 start_suite "Resolve names across hosts (with and without IPAM), and repopulate on restart"
 
-weave_on $HOST1 launch-router -iprange $UNIVERSE
-weave_on $HOST2 launch-router -iprange $UNIVERSE $HOST1
+weave_on $HOST1 launch-router --ipalloc-range $UNIVERSE
+weave_on $HOST2 launch-router --ipalloc-range $UNIVERSE $HOST1
 
 start_container          $HOST2 $C2/24 --name=c2 -h $NAME2
 start_container_with_dns $HOST1 $C1/24 --name=c1

test/270_use_name_as_hostname_test.sh

@@ -22,7 +22,7 @@ assert_expected_fqdn() {
 
 start_suite "Use container name as hostname"
 
-weave_on $HOST1 launch -iprange 10.2.0.0/24
+weave_on $HOST1 launch --ipalloc-range 10.2.0.0/24
 
 assert_expected_fqdn "$NAME.$DOMAIN" --name=$NAME
 assert_expected_fqdn "$NAME.$DOMAIN" --name $NAME

test/500_weave_multi_cidr_test.sh

@@ -73,7 +73,7 @@ start_suite "Weave run/start/attach/detach/expose/hide with multiple cidr argume
 # specific address, i.e. we are assuming that IPAM always returns the
 # lowest available address in the subnet
 
-weave_on $HOST1 launch-router -iprange 10.2.3.0/24
+weave_on $HOST1 launch-router --ipalloc-range 10.2.3.0/24
 launch_dns_on $HOST1 10.254.254.254/24
 
 # Run container with three cidrs

test/620_proxy_entrypoint_command_test.sh

@@ -26,7 +26,7 @@ run_container "grep ^1$ /sys/class/net/ethwe/carrier"
 build_image false '["/bin/false"]' ''
 run_container "--entrypoint='grep' false ^1$ /sys/class/net/ethwe/carrier"
 
-weave_on $HOST1 launch-router -iprange 10.2.2.0/24
+weave_on $HOST1 launch-router --ipalloc-range 10.2.2.0/24
 docker_on $HOST1 kill weaveproxy
 weave_on $HOST1 launch-proxy
 

test/660_proxy_ipam_test.sh

@@ -17,8 +17,8 @@ assert_no_ethwe() {
 
 start_suite "Ping proxied containers over cross-host weave network (with IPAM)"
 
-weave_on $HOST1 launch-router -iprange $UNIVERSE
-weave_on $HOST2 launch-router -iprange $UNIVERSE $HOST1
+weave_on $HOST1 launch-router --ipalloc-range $UNIVERSE
+weave_on $HOST2 launch-router --ipalloc-range $UNIVERSE $HOST1
 weave_on $HOST1 launch-proxy
 weave_on $HOST2 launch-proxy --no-default-ipalloc
 

weave

@@ -1148,30 +1148,6 @@ deprecation_warnings() {
             -no-default-ipam|--no-default-ipam)
                 deprecation_warning $1 "--no-default-ipalloc"
                 ;;
-            --tlscacert|--tlscacert=*)
-                deprecation_warning "--tlscacert" "--tls-cacert"
-                [ "$1" == "--tlscacert" ] && shift
-                ;;
-            --tls-cacert)
-                shift
-                ;;
-            --tlscert|--tlscert=*)
-                deprecation_warning "--tlscert" "--tls-cert"
-                [ "$1" == "--tlscert" ] && shift
-                ;;
-            --tls-cert)
-                shift
-                ;;
-            --tlskey|--tlskey=*)
-                deprecation_warning "--tlskey" "--tls-key"
-                [ "$1" == "--tlskey" ] && shift
-                ;;
-            --tls-key)
-                shift
-                ;;
-            --tlsverify)
-                deprecation_warning "--tlsverify" "--tls-verify"
-                ;;
         esac
         shift
     done