Add release v1.9.5

Fixes #2808. Improve hairpin log messages.

.gitmodules

@@ -61,9 +61,6 @@
 [submodule "vendor/github.com/hashicorp/go-cleanhttp"]
 	path = vendor/github.com/hashicorp/go-cleanhttp
 	url = http://github.com/hashicorp/go-cleanhttp
-[submodule "vendor/github.com/appc/cni"]
-	path = vendor/github.com/appc/cni
-	url = https://github.com/appc/cni
 [submodule "vendor/github.com/coreos/go-iptables"]
 	path = vendor/github.com/coreos/go-iptables
 	url = https://github.com/coreos/go-iptables
@@ -124,3 +121,6 @@
 [submodule "vendor/github.com/weaveworks/common"]
 	path = vendor/github.com/weaveworks/common
 	url = https://github.com/weaveworks/common
+[submodule "vendor/github.com/containernetworking/cni"]
+	path = vendor/github.com/containernetworking/cni
+	url = https://github.com/containernetworking/cni

CHANGELOG.md

@@ -1,3 +1,46 @@
+## Release 1.9.5
+
+Bug fixes and minor improvements
+
+* Improve log messages generated if "hairpin" conditions are detected,
+  to make clear which kind is likely to cause problems #2808/#2926
+* Filter out IPv6 peer addresses from Kubernetes; Weave Net currently
+  only supports IPv4 #2904/#2912
+* Fix rare crash during initialization of weave-kube #2893/#2892
+* Include overlay and encryption modes in checkpoint reports, in case
+  this is relevant to a version upgrade #2771/#2907
+
+Build and Testing
+
+* Ensure CI build can run gcloud tools  #2887
+* Prevent kubeadm from upgrading Kubernetes if we are trying to test an older version #2886
+* Upgrade build scripts to support Kubernetes 1.6 #2880
+
+[Full list of changes](https://github.com/weaveworks/weave/milestone/54?closed=1).
+
+## Release 1.9.4
+
+Bug fixes and minor improvements
+
+* Support Kubernetes 1.6 by creating a new DaemonSet #2777,#2801
+* Support Kubernetes 1.6 by allowing CNI callers to send a
+  network-delete request for a container that is not running or has
+  never been attached to the network #2850
+* Leave non-weave ipsets alone in Network Policy Controller (e.g. when
+  running Weave Net alonside keepalived-vip) #2751,#2846
+* Fix various small issues revealed by 'staticcheck' tool #2843,#2857
+* Avoid leaving 'defunct' processes when weave-kube container restarts #2836,#2845
+* When using the CNI plugin with a non-standard network configuration
+  file, the weave bridge could get the same IP as a container, if
+  'weave expose' hadn't run at that point #2839,#2856
+
+Build and Testing
+
+* Check that no defunct processes remain after each test #2852
+* Update build and test scripts to work with Kubernetes 1.6 beta #2851
+
+[Full list of changes](https://github.com/weaveworks/weave/milestone/53?closed=1).
+
 ## Release 1.9.3
 
 Bug fixes and minor improvements

Makefile

@@ -173,6 +173,8 @@ ifeq ($(BUILD_IN_CONTAINER),true)
 # It bind-mounts the source into the container and passes all important variables
 exes $(EXES) tests lint: $(BUILD_UPTODATE)
 	git submodule update --init
+# Containernetworking has another copy of vishvananda/netlink which leads to duplicate definitions
+	-@rm -r vendor/github.com/containernetworking/cni/vendor
 	@mkdir -p $(shell pwd)/.pkg
 	$(SUDO) docker run $(RM) $(RUN_FLAGS) \
 	    -v $(shell pwd):/go/src/github.com/weaveworks/weave \

bin/release

@@ -90,6 +90,7 @@ build() {
     ## (library versions?)
     sed -i "/SCRIPT_VERSION=/ c\SCRIPT_VERSION=\"$VERSION\"" ./weave
     sed -i -e "s/:latest/:$VERSION/" -e "/imagePullPolicy: Always/d" ./prog/weave-kube/weave-daemonset.yaml
+    sed -i -e "s/:latest/:$VERSION/" -e "/imagePullPolicy: Always/d" ./prog/weave-kube/weave-daemonset-k8s-1.6.yaml
     make SUDO=$SUDO WEAVE_VERSION=$VERSION DOCKERHUB_USER=$DOCKERHUB_USER
 
     if make tests; then
@@ -165,6 +166,13 @@ draft() {
         --name "weave-daemonset.yaml" \
         --file "./prog/weave-kube/weave-daemonset.yaml"
 
+    github-release upload \
+        --user $GITHUB_USER \
+        --repo weave \
+        --tag $LATEST_TAG \
+        --name "weave-daemonset-k8s-1.6.yaml" \
+        --file "./prog/weave-kube/weave-daemonset-k8s-1.6.yaml"
+
     echo "** Draft $TYPE $RELEASE_NAME $VERSION created at"
     echo -e "\thttps://github.com/$GITHUB_USER/weave/releases/$LATEST_TAG"
 }
@@ -251,6 +259,13 @@ publish() {
             --name "weave-daemonset.yaml" \
             --file "./prog/weave-kube/weave-daemonset.yaml"
 
+        github-release upload \
+            --user $GITHUB_USER \
+            --repo weave \
+            --tag latest_release \
+            --name "weave-daemonset-k8s-1.6.yaml" \
+            --file "./prog/weave-kube/weave-daemonset-k8s-1.6.yaml"
+
         echo "** Release $RELEASE_NAME $VERSION published at"
         echo -e "\thttps://github.com/$GITHUB_USER/weave/releases/$LATEST_TAG"
         echo -e "\thttps://github.com/$GITHUB_USER/weave/releases/latest_release"

circle.yml

@@ -11,7 +11,7 @@ machine:
   environment:
     GOPATH: /home/ubuntu:$GOPATH
     SRCDIR: /home/ubuntu/src/github.com/weaveworks/weave
-    PATH: $PATH:$HOME/.local/bin
+    PATH: $PATH:$HOME/.local/bin:/opt/google-cloud-sdk/bin
     CLOUDSDK_CORE_DISABLE_PROMPTS: 1
     STATE: /home/ubuntu/state.env
     # Base name of VMs for integration tests:

ipam/allocator.go

@@ -210,9 +210,9 @@ func (alloc *Allocator) doOperation(op operation, ops *[]operation) {
 //  already succeeded.  If it is on the queue, we call
 //  cancel on it, allowing callers waiting for the resultChans
 //  to unblock.
-func (alloc *Allocator) cancelOp(op operation, ops *[]operation) {
+func (alloc *Allocator) cancelOp(opToCancel operation, ops *[]operation) {
 	for i, op := range *ops {
-		if op == op {
+		if op == opToCancel {
 			*ops = append((*ops)[:i], (*ops)[i+1:]...)
 			op.Cancel()
 			break
@@ -265,6 +265,10 @@ func (alloc *Allocator) tryPendingOps() {
 	alloc.tryOps(&alloc.pendingAllocates)
 }
 
+func (alloc *Allocator) havePendingOps() bool {
+	return len(alloc.pendingPrimes)+len(alloc.pendingClaims)+len(alloc.pendingAllocates) > 0
+}
+
 func (alloc *Allocator) spaceRequestDenied(sender mesh.PeerName, r address.Range) {
 	for i := 0; i < len(alloc.pendingClaims); {
 		claim := alloc.pendingClaims[i].(*claim)
@@ -696,8 +700,12 @@ func (alloc *Allocator) actorLoop(actionChan <-chan func(), stopChan <-chan stru
 			// Retry things in case messages got lost between here and recipients
 			if alloc.awaitingConsensus {
 				alloc.propose()
-			} else {
-				alloc.tryPendingOps()
+			} else if alloc.havePendingOps() {
+				if alloc.ring.Empty() {
+					alloc.establishRing()
+				} else {
+					alloc.tryPendingOps()
+				}
 			}
 			alloc.removeDeadContainers()
 		}

ipam/allocator_test.go

@@ -186,6 +186,7 @@ func TestAllocatorClaim(t *testing.T) {
 	alloc.Prime()
 	// Do an allocate on the other peer, which we will try to claim later
 	addrx, err := allocs[0].Allocate(container1, subnet, true, returnFalse)
+	require.NoError(t, err)
 	// Should not get the address we pre-claimed
 	require.NotEqual(t, addrx, preAddr)
 	router.Flush()

ipam/space/space_test.go

@@ -52,12 +52,12 @@ func TestLowlevel(t *testing.T) {
 
 	s := New()
 	require.Equal(t, address.Count(0), s.NumFreeAddresses())
-	ok, got := s.Allocate(address.NewRange(0, 1000))
+	ok, _ := s.Allocate(address.NewRange(0, 1000))
 	require.False(t, ok, "allocate in empty space should fail")
 
 	s.Add(100, 100)
 	require.Equal(t, address.Count(100), s.NumFreeAddresses())
-	ok, got = s.Allocate(address.NewRange(0, 1000))
+	ok, got := s.Allocate(address.NewRange(0, 1000))
 	require.True(t, ok && got == 100, "allocate")
 	require.Equal(t, address.Count(99), s.NumFreeAddresses())
 	require.NoError(t, s.Claim(150))
@@ -68,6 +68,7 @@ func TestLowlevel(t *testing.T) {
 	wt.AssertErrorInterface(t, (*error)(nil), s.Free(100), "double free")
 
 	r, ok := s.Donate(address.NewRange(0, 1000))
+	require.True(t, ok, "donate")
 	require.Equal(t, address.NewRange(0xa0, 0x20), r, "donate")
 
 	// test Donate when addresses are scarce
@@ -78,6 +79,7 @@ func TestLowlevel(t *testing.T) {
 	require.NoError(t, s.Claim(0))
 	require.NoError(t, s.Claim(2))
 	r, ok = s.Donate(address.NewRange(0, 1000))
+	require.True(t, ok, "donate")
 	require.Equal(t, address.NewRange(1, 1), r, "donate")
 	r, ok = s.Donate(address.NewRange(0, 1000))
 	require.True(t, !ok, "donate should fail")

npc/constants.go

@@ -6,4 +6,6 @@ const (
 	MainChain    = "WEAVE-NPC"
 	DefaultChain = "WEAVE-NPC-DEFAULT"
 	IngressChain = "WEAVE-NPC-INGRESS"
+
+	IpsetNamePrefix = "weave-"
 )

npc/ipset/ipset.go

@@ -2,6 +2,7 @@ package ipset
 
 import (
 	"os/exec"
+	"strings"
 
 	"github.com/pkg/errors"
 )
@@ -22,6 +23,8 @@ type Interface interface {
 	Flush(ipsetName Name) error
 	Destroy(ipsetName Name) error
 
+	List(prefix string) ([]Name, error)
+
 	FlushAll() error
 	DestroyAll() error
 }
@@ -72,6 +75,24 @@ func (i *ipset) DestroyAll() error {
 	return doExec("destroy")
 }
 
+// Fetch a list of all existing sets with a given prefix
+func (i *ipset) List(prefix string) ([]Name, error) {
+	output, err := exec.Command("ipset", "list", "-name", "-output", "plain").Output()
+	if err != nil {
+		return nil, err
+	}
+
+	var selected []Name
+	sets := strings.Split(string(output), "\n")
+	for _, v := range sets {
+		if strings.HasPrefix(v, prefix) {
+			selected = append(selected, Name(v))
+		}
+	}
+
+	return selected, err
+}
+
 func doExec(args ...string) error {
 	if output, err := exec.Command("ipset", args...).CombinedOutput(); err != nil {
 		return errors.Wrapf(err, "ipset %v failed: %s", args, output)

npc/selector.go

@@ -29,7 +29,7 @@ func newSelectorSpec(json *unversioned.LabelSelector, nsName string, ipsetType i
 		// We prefix the selector string with the namespace name when generating
 		// the shortname because you can specify the same selector in multiple
 		// namespaces - we need those to map to distinct ipsets
-		ipsetName: ipset.Name("weave-" + shortName(nsName+":"+key)),
+		ipsetName: ipset.Name(IpsetNamePrefix + shortName(nsName+":"+key)),
 		ipsetType: ipsetType}, nil
 }
 

plugin/ipam/cni.go

@@ -5,19 +5,24 @@ import (
 	"fmt"
 	"net"
 
-	"github.com/appc/cni/pkg/skel"
-	"github.com/appc/cni/pkg/types"
+	"github.com/containernetworking/cni/pkg/skel"
+	"github.com/containernetworking/cni/pkg/types"
+	"github.com/containernetworking/cni/pkg/types/current"
 )
 
 func (i *Ipam) CmdAdd(args *skel.CmdArgs) error {
+	var conf types.NetConf
+	if err := json.Unmarshal(args.StdinData, &conf); err != nil {
+		return fmt.Errorf("failed to load netconf: %v", err)
+	}
 	result, err := i.Allocate(args)
 	if err != nil {
 		return err
 	}
-	return result.Print()
+	return types.PrintResult(result, conf.CNIVersion)
 }
 
-func (i *Ipam) Allocate(args *skel.CmdArgs) (*types.Result, error) {
+func (i *Ipam) Allocate(args *skel.CmdArgs) (types.Result, error) {
 	// extract the things we care about
 	conf, err := loadIPAMConf(args.StdinData)
 	if err != nil {
@@ -46,12 +51,13 @@ func (i *Ipam) Allocate(args *skel.CmdArgs) (*types.Result, error) {
 	if err != nil {
 		return nil, err
 	}
-	result := &types.Result{
-		IP4: &types.IPConfig{
-			IP:      *ipnet,
+	result := &current.Result{
+		IPs: []*current.IPConfig{{
+			Version: "4",
+			Address: *ipnet,
 			Gateway: conf.Gateway,
-			Routes:  conf.Routes,
-		},
+		}},
+		Routes: conf.Routes,
 	}
 	return result, nil
 }
@@ -65,9 +71,9 @@ func (i *Ipam) Release(args *skel.CmdArgs) error {
 }
 
 type ipamConf struct {
-	Subnet  string        `json:"subnet,omitempty"`
-	Gateway net.IP        `json:"gateway,omitempty"`
-	Routes  []types.Route `json:"routes"`
+	Subnet  string         `json:"subnet,omitempty"`
+	Gateway net.IP         `json:"gateway,omitempty"`
+	Routes  []*types.Route `json:"routes"`
 }
 
 type netConf struct {

plugin/net/cni.go

@@ -5,11 +5,14 @@ import (
 	"encoding/json"
 	"fmt"
 	"net"
+	"os"
+	"strings"
 	"syscall"
 
-	"github.com/appc/cni/pkg/ipam"
-	"github.com/appc/cni/pkg/skel"
-	"github.com/appc/cni/pkg/types"
+	"github.com/containernetworking/cni/pkg/ipam"
+	"github.com/containernetworking/cni/pkg/skel"
+	"github.com/containernetworking/cni/pkg/types"
+	"github.com/containernetworking/cni/pkg/types/current"
 	"github.com/vishvananda/netlink"
 	"github.com/vishvananda/netns"
 	weaveapi "github.com/weaveworks/weave/api"
@@ -40,17 +43,26 @@ func loadNetConf(bytes []byte) (*NetConf, error) {
 	return n, nil
 }
 
-func (c *CNIPlugin) getIP(ipamType string, args *skel.CmdArgs) (result *types.Result, err error) {
+func (c *CNIPlugin) getIP(ipamType string, args *skel.CmdArgs) (newResult *current.Result, err error) {
+	var result types.Result
 	// Default IPAM is Weave's own
 	if ipamType == "" {
 		result, err = ipamplugin.NewIpam(c.weave).Allocate(args)
 	} else {
 		result, err = ipam.ExecAdd(ipamType, args.StdinData)
 	}
-	if err == nil && result.IP4 == nil {
+	if err != nil {
+		return nil, err
+	}
+	if result == nil {
+		return nil, fmt.Errorf("Received no usable result from IPAM plugin")
+	}
+	newResult, err = current.NewResultFromResult(result)
+	// Check if ipam returned no results without error
+	if err == nil && len(newResult.IPs) == 0 {
 		return nil, fmt.Errorf("IPAM plugin failed to allocate IP address")
 	}
-	return result, err
+	return newResult, err
 }
 
 func (c *CNIPlugin) CmdAdd(args *skel.CmdArgs) error {
@@ -70,28 +82,35 @@ func (c *CNIPlugin) CmdAdd(args *skel.CmdArgs) error {
 	if err != nil {
 		return fmt.Errorf("unable to allocate IP address: %s", err)
 	}
+	// Only expecting one address
+	ip := result.IPs[0]
 
 	// If config says nothing about routes or gateway, default one will be via the bridge
-	if result.IP4.Routes == nil && result.IP4.Gateway == nil {
-		bridgeIP, err := weavenet.FindBridgeIP(conf.BrName, &result.IP4.IP)
+	if len(result.Routes) == 0 && ip.Gateway == nil {
+		bridgeIP, err := weavenet.FindBridgeIP(conf.BrName, &ip.Address)
 		if err == weavenet.ErrBridgeNoIP {
 			bridgeArgs := *args
 			bridgeArgs.ContainerID = "weave:expose"
+			// It would be better if libcni let us send just the desired parameters,
+			// but there is a bug: https://github.com/containernetworking/cni/issues/410
+			// so just blank out the one we want to change
+			os.Setenv("CNI_CONTAINERID", bridgeArgs.ContainerID)
 			bridgeIPResult, err := c.getIP(conf.IPAM.Type, &bridgeArgs)
 			if err != nil {
 				return fmt.Errorf("unable to allocate IP address for bridge: %s", err)
 			}
-			if err := assignBridgeIP(conf.BrName, bridgeIPResult.IP4.IP); err != nil {
+			bridgeCIDR := bridgeIPResult.IPs[0].Address
+			if err := assignBridgeIP(conf.BrName, bridgeCIDR); err != nil {
 				return fmt.Errorf("unable to assign IP address to bridge: %s", err)
 			}
-			if err := weavenet.ExposeNAT(bridgeIPResult.IP4.IP); err != nil {
+			if err := weavenet.ExposeNAT(bridgeCIDR); err != nil {
 				return fmt.Errorf("unable to create NAT rules: %s", err)
 			}
-			bridgeIP = bridgeIPResult.IP4.IP.IP
+			bridgeIP = bridgeCIDR.IP
 		} else if err != nil {
 			return err
 		}
-		result.IP4.Gateway = bridgeIP
+		result.IPs[0].Gateway = bridgeIP
 	}
 
 	ns, err := netns.GetFromPath(args.Netns)
@@ -110,20 +129,20 @@ func (c *CNIPlugin) CmdAdd(args *skel.CmdArgs) error {
 		id = fmt.Sprintf("%x", data)
 	}
 
-	if err := weavenet.AttachContainer(args.Netns, id, args.IfName, conf.BrName, conf.MTU, false, []*net.IPNet{&result.IP4.IP}, false); err != nil {
+	if err := weavenet.AttachContainer(args.Netns, id, args.IfName, conf.BrName, conf.MTU, false, []*net.IPNet{&ip.Address}, false); err != nil {
 		return err
 	}
 	if err := weavenet.WithNetNSLinkUnsafe(ns, args.IfName, func(link netlink.Link) error {
-		return setupRoutes(link, args.IfName, result.IP4.IP, result.IP4.Gateway, result.IP4.Routes)
+		return setupRoutes(link, args.IfName, ip.Address, ip.Gateway, result.Routes)
 	}); err != nil {
 		return fmt.Errorf("error setting up routes: %s", err)
 	}
 
 	result.DNS = conf.DNS
-	return result.Print()
+	return types.PrintResult(result, conf.CNIVersion)
 }
 
-func setupRoutes(link netlink.Link, name string, ipnet net.IPNet, gw net.IP, routes []types.Route) error {
+func setupRoutes(link netlink.Link, name string, ipnet net.IPNet, gw net.IP, routes []*types.Route) error {
 	var err error
 	if routes == nil { // If config says nothing about routes, add a default one
 		if !ipnet.Contains(gw) {
@@ -133,7 +152,7 @@ func setupRoutes(link netlink.Link, name string, ipnet net.IPNet, gw net.IP, rou
 				return err
 			}
 		}
-		routes = []types.Route{{Dst: zeroNetwork}}
+		routes = []*types.Route{{Dst: zeroNetwork}}
 	}
 	for _, r := range routes {
 		if r.GW != nil {
@@ -170,8 +189,11 @@ func (c *CNIPlugin) CmdDel(args *skel.CmdArgs) error {
 		return err
 	}
 
-	if _, err = weavenet.WithNetNS(args.Netns, "del-iface", args.IfName); err != nil {
-		return fmt.Errorf("error removing interface %q: %s", args.IfName, err)
+	// As of CNI 0.3 spec, runtimes can send blank if they just want the address deallocated
+	if args.Netns != "" {
+		if _, err = weavenet.WithNetNS(args.Netns, "del-iface", args.IfName); err != nil {
+			return fmt.Errorf("error removing interface %q: %s", args.IfName, err)
+		}
 	}
 
 	// Default IPAM is Weave's own
@@ -180,6 +202,10 @@ func (c *CNIPlugin) CmdDel(args *skel.CmdArgs) error {
 	} else {
 		err = ipam.ExecDel(conf.IPAM.Type, args.StdinData)
 	}
+	// Hack - don't know how we should detect this situation properly
+	if args.Netns == "" && strings.Contains(err.Error(), "no addresses") {
+		err = nil
+	}
 	if err != nil {
 		return fmt.Errorf("unable to release IP address: %s", err)
 	}

prog/kube-peers/main.go

@@ -3,6 +3,7 @@ package main
 import (
 	"fmt"
 	"log"
+	"net"
 
 	"k8s.io/client-go/kubernetes"
 	api "k8s.io/client-go/pkg/api/v1"
@@ -35,10 +36,25 @@ func getKubePeers() ([]string, error) {
 	}
 	addresses := make([]string, 0, len(nodeList.Items))
 	for _, peer := range nodeList.Items {
+		var internalIP, externalIP string
 		for _, addr := range peer.Status.Addresses {
-			if addr.Type == "InternalIP" {
-				addresses = append(addresses, addr.Address)
+			// Check it's a valid ipv4 address
+			ip := net.ParseIP(addr.Address)
+			if ip == nil || ip.To4() == nil {
+				continue
 			}
+			if addr.Type == "InternalIP" {
+				internalIP = ip.To4().String()
+			} else if addr.Type == "ExternalIP" {
+				externalIP = ip.To4().String()
+			}
+		}
+
+		// Fallback for cases where a Node has an ExternalIP but no InternalIP
+		if internalIP != "" {
+			addresses = append(addresses, internalIP)
+		} else if externalIP != "" {
+			addresses = append(addresses, externalIP)
 		}
 	}
 	return addresses, nil

prog/plugin/main.go

@@ -94,7 +94,7 @@ func run(dockerClient *docker.Client, weave *weaveapi.Client, address, meshAddre
 	}
 	go serveStatus(statusListener)
 	sigChan := make(chan os.Signal, 1)
-	signal.Notify(sigChan, os.Interrupt, os.Kill, syscall.SIGTERM)
+	signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
 
 	select {
 	case sig := <-sigChan:

prog/weave-kube/launch.sh

@@ -117,7 +117,7 @@ post_start_actions() {
 
 post_start_actions &
 
-exec /home/weave/weaver $EXTRA_ARGS --port=6783 $BRIDGE_OPTIONS \
+/home/weave/weaver $EXTRA_ARGS --port=6783 $BRIDGE_OPTIONS \
      --http-addr=$HTTP_ADDR --status-addr=$STATUS_ADDR --docker-api='' --no-dns \
      --ipalloc-range=$IPALLOC_RANGE $NICKNAME_ARG \
      --ipalloc-init $IPALLOC_INIT \

prog/weave-kube/weave-daemonset-k8s-1.6.yaml

@@ -0,0 +1,120 @@
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: weave-net
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - pods
+  - namespaces
+  - nodes
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - extensions
+  resources:
+  - networkpolicies
+  verbs:
+  - get
+  - list
+  - watch
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: weave-net
+  namespace: kube-system
+---
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: weave-net
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: weave-net
+subjects:
+- kind: ServiceAccount
+  name: weave-net
+  namespace: kube-system
+---
+apiVersion: extensions/v1beta1
+kind: DaemonSet
+metadata:
+  name: weave-net
+  namespace: kube-system
+spec:
+  template:
+    metadata:
+      labels:
+        name: weave-net
+    spec:
+      hostNetwork: true
+      hostPID: true
+      containers:
+        - name: weave
+          image: weaveworks/weave-kube:latest
+          imagePullPolicy: Always
+          command:
+            - /home/weave/launch.sh
+          livenessProbe:
+            initialDelaySeconds: 30
+            httpGet:
+              host: 127.0.0.1
+              path: /status
+              port: 6784
+          securityContext:
+            privileged: true
+          volumeMounts:
+            - name: weavedb
+              mountPath: /weavedb
+            - name: cni-bin
+              mountPath: /host/opt
+            - name: cni-bin2
+              mountPath: /host/home
+            - name: cni-conf
+              mountPath: /host/etc
+            - name: dbus
+              mountPath: /host/var/lib/dbus
+            - name: lib-modules
+              mountPath: /lib/modules
+          resources:
+            requests:
+              cpu: 10m
+        - name: weave-npc
+          image: weaveworks/weave-npc:latest
+          imagePullPolicy: Always
+          resources:
+            requests:
+              cpu: 10m
+          securityContext:
+            privileged: true
+      restartPolicy: Always
+      tolerations:
+      - key: node-role.kubernetes.io/master
+        effect: NoSchedule
+      serviceAccountName: weave-net
+      securityContext:
+        seLinuxOptions:
+          type: spc_t
+      volumes:
+        - name: weavedb
+          emptyDir: {}
+        - name: cni-bin
+          hostPath:
+            path: /opt
+        - name: cni-bin2
+          hostPath:
+            path: /home
+        - name: cni-conf
+          hostPath:
+            path: /etc
+        - name: dbus
+          hostPath:
+            path: /var/lib/dbus
+        - name: lib-modules
+          hostPath:
+            path: /lib/modules

prog/weave-npc/main.go

@@ -80,14 +80,22 @@ func resetIPTables(ipt *iptables.IPTables) error {
 }
 
 func resetIPSets(ips ipset.Interface) error {
-	// TODO should restrict ipset operations to the `weave-` prefix:
+	// Remove ipsets prefixed `weave-` only
 
-	if err := ips.FlushAll(); err != nil {
+	sets, err := ips.List(npc.IpsetNamePrefix)
+	if err != nil {
+		common.Log.Errorf("Failed to retrieve list of ipsets")
 		return err
 	}
 
-	if err := ips.DestroyAll(); err != nil {
-		return err
+	common.Log.Debugf("Got list of ipsets: %v", sets)
+
+	for _, s := range sets {
+		common.Log.Debugf("Destroying ipsets '%s'", string(s))
+		if err := ips.Destroy(s); err != nil {
+			common.Log.Errorf("Failed to destroy ipset '%s'", string(s))
+			return err
+		}
 	}
 
 	return nil

prog/weaver/checkpoint.go

@@ -6,6 +6,7 @@ import (
 	"time"
 
 	"github.com/weaveworks/go-checkpoint"
+	weave "github.com/weaveworks/weave/router"
 )
 
 var checker *checkpoint.Checker
@@ -16,7 +17,7 @@ const (
 	updateCheckPeriod = 6 * time.Hour
 )
 
-func checkForUpdates(dockerVersion string, network string) {
+func checkForUpdates(dockerVersion string, router *weave.NetworkRouter) {
 	newVersion.Store("")
 	success.Store(true)
 
@@ -51,9 +52,6 @@ func checkForUpdates(dockerVersion string, network string) {
 		"docker-version": dockerVersion,
 		"kernel-version": kernelVersion,
 	}
-	if network != "" {
-		flags["network"] = network
-	}
 
 	// Start background version checking
 	params := checkpoint.CheckParams{
@@ -61,6 +59,21 @@ func checkForUpdates(dockerVersion string, network string) {
 		Version:       version,
 		SignatureFile: "",
 		Flags:         flags,
+		ExtraFlags:    func() []checkpoint.Flag { return checkpointFlags(router) },
 	}
 	checker = checkpoint.CheckInterval(&params, updateCheckPeriod, handleResponse)
 }
+
+func checkpointFlags(router *weave.NetworkRouter) []checkpoint.Flag {
+	flags := []checkpoint.Flag{}
+	status := weave.NewNetworkRouterStatus(router)
+	for _, conn := range status.Connections {
+		if connectionName, ok := conn.Attrs["name"].(string); ok {
+			if _, encrypted := conn.Attrs["encrypted"]; encrypted {
+				connectionName = connectionName + " encrypted"
+			}
+			flags = append(flags, checkpoint.Flag{Key: "network", Value: connectionName})
+		}
+	}
+	return flags
+}

prog/weaver/main.go

@@ -231,7 +231,8 @@ func main() {
 
 	if bridge != nil {
 		if err := weavenet.DetectHairpin("vethwe-bridge", Log); err != nil {
-			Log.Errorf("DetectHairpin failed: %s", err)
+			Log.Errorf("Setting may cause connectivity issues : %s", err)
+			Log.Infof("Hairpin mode may have been enabled by other software on this machine")
 		}
 	}
 
@@ -254,7 +255,8 @@ func main() {
 	checkFatal(err)
 	defer db.Close()
 
-	router := weave.NewNetworkRouter(config, networkConfig, name, nickName, overlay, db)
+	router, err := weave.NewNetworkRouter(config, networkConfig, name, nickName, overlay, db)
+	checkFatal(err)
 	Log.Println("Our name is", router.Ourself)
 
 	if peers, err = router.InitialPeers(resume, peers); err != nil {
@@ -274,11 +276,7 @@ func main() {
 		dockerVersion = dockerCli.DockerVersion()
 	}
 
-	network := ""
-	if isAWSVPC {
-		network = "awsvpc"
-	}
-	checkForUpdates(dockerVersion, network)
+	checkForUpdates(dockerVersion, router)
 
 	observeContainers := func(o docker.ContainerObserver) {
 		if dockerCli != nil {
@@ -476,7 +474,9 @@ func createAllocator(router *weave.NetworkRouter, config ipamConfig, preClaims [
 
 	allocator := ipam.NewAllocator(c)
 
-	allocator.SetInterfaces(router.NewGossip("IPallocation", allocator))
+	gossip, err := router.NewGossip("IPallocation", allocator)
+	checkFatal(err)
+	allocator.SetInterfaces(gossip)
 	allocator.Start()
 	router.Peers.OnGC(func(peer *mesh.Peer) { allocator.PeerGone(peer.Name) })
 
@@ -486,7 +486,9 @@ func createAllocator(router *weave.NetworkRouter, config ipamConfig, preClaims [
 func createDNSServer(config dnsConfig, router *mesh.Router, isKnownPeer func(mesh.PeerName) bool) (*nameserver.Nameserver, *nameserver.DNSServer) {
 	ns := nameserver.New(router.Ourself.Peer.Name, config.Domain, isKnownPeer)
 	router.Peers.OnGC(func(peer *mesh.Peer) { ns.PeerGone(peer.Name) })
-	ns.SetGossip(router.NewGossip("nameserver", ns))
+	gossip, err := router.NewGossip("nameserver", ns)
+	checkFatal(err)
+	ns.SetGossip(gossip)
 	upstream := nameserver.NewUpstream(config.ResolvConf, config.EffectiveListenAddress)
 	dnsserver, err := nameserver.NewDNSServer(ns, config.Domain, config.ListenAddress,
 		upstream, uint32(config.TTL), config.ClientTimeout)

prog/weaveutil/cni.go

@@ -3,7 +3,8 @@ package main
 import (
 	"os"
 
-	cni "github.com/appc/cni/pkg/skel"
+	cni "github.com/containernetworking/cni/pkg/skel"
+	"github.com/containernetworking/cni/pkg/version"
 
 	weaveapi "github.com/weaveworks/weave/api"
 	"github.com/weaveworks/weave/common"
@@ -14,13 +15,13 @@ import (
 func cniNet(args []string) error {
 	weave := weaveapi.NewClient(os.Getenv("WEAVE_HTTP_ADDR"), common.Log)
 	n := netplugin.NewCNIPlugin(weave)
-	cni.PluginMain(n.CmdAdd, n.CmdDel)
+	cni.PluginMain(n.CmdAdd, n.CmdDel, version.PluginSupports("0.1.0", "0.2.0", "0.3.0"))
 	return nil
 }
 
 func cniIPAM(args []string) error {
 	weave := weaveapi.NewClient(os.Getenv("WEAVE_HTTP_ADDR"), common.Log)
 	i := ipamplugin.NewIpam(weave)
-	cni.PluginMain(i.CmdAdd, i.CmdDel)
+	cni.PluginMain(i.CmdAdd, i.CmdDel, version.PluginSupports("0.1.0", "0.2.0", "0.3.0"))
 	return nil
 }

prog/weaveutil/docker_tls_args.go

@@ -45,7 +45,6 @@ func dockerTLSArgs(args []string) error {
 			switch {
 			case arg == "-d" || arg == "daemon":
 				isDaemon = true
-				break
 			case arg == "--tls", arg == "--tlsverify":
 				tlsArgs = append(tlsArgs, arg)
 			case strings.HasPrefix(arg, "--tls"):

prog/weaveutil/unique_id.go

@@ -16,6 +16,6 @@ func uniqueID(args []string) error {
 	if err != nil {
 		return err
 	}
-	fmt.Printf(uid)
+	fmt.Print(uid)
 	return nil
 }

router/fastdp.go

@@ -1224,7 +1224,7 @@ func (fastdp *FastDatapath) send(fops FlowOp, frame []byte, lock *fastDatapathLo
 	}
 
 	if fastdp.isHairpinFlow(&flow) {
-		log.Error("Vetoed installation of hairpin flow ", flow)
+		log.Warning("Vetoed installation of hairpin flow ", flow)
 		return
 	}
 

router/network_router.go

@@ -51,7 +51,7 @@ type NetworkRouter struct {
 	db   db.DB
 }
 
-func NewNetworkRouter(config mesh.Config, networkConfig NetworkConfig, name mesh.PeerName, nickName string, overlay NetworkOverlay, db db.DB) *NetworkRouter {
+func NewNetworkRouter(config mesh.Config, networkConfig NetworkConfig, name mesh.PeerName, nickName string, overlay NetworkOverlay, db db.DB) (*NetworkRouter, error) {
 	if overlay == nil {
 		overlay = NullNetworkOverlay{}
 	}
@@ -59,7 +59,11 @@ func NewNetworkRouter(config mesh.Config, networkConfig NetworkConfig, name mesh
 		networkConfig.Bridge = NullBridge{}
 	}
 
-	router := &NetworkRouter{Router: mesh.NewRouter(config, name, nickName, overlay, common.LogLogger()), NetworkConfig: networkConfig, db: db}
+	meshRouter, err := mesh.NewRouter(config, name, nickName, overlay, common.LogLogger())
+	if err != nil {
+		return nil, err
+	}
+	router := &NetworkRouter{Router: meshRouter, NetworkConfig: networkConfig, db: db}
 	router.Peers.OnInvalidateShortIDs(overlay.InvalidateShortIDs)
 	router.Routes.OnChange(overlay.InvalidateRoutes)
 	router.Macs = NewMacCache(macMaxAge,
@@ -67,7 +71,7 @@ func NewNetworkRouter(config mesh.Config, networkConfig NetworkConfig, name mesh
 			log.Println("Expired MAC", mac, "at", peer)
 		})
 	router.Peers.OnGC(func(peer *mesh.Peer) { router.Macs.Delete(peer) })
-	return router
+	return router, nil
 }
 
 // Start listening for TCP connections, locally captured packets, and

router/sleeve.go

@@ -6,7 +6,6 @@
 package router
 
 import (
-	"bytes"
 	"encoding/binary"
 	"fmt"
 	"io"
@@ -1039,6 +1038,9 @@ func (sender *udpSenderDF) dial() error {
 	laddr := &net.IPAddr{IP: sender.localIP}
 	raddr := &net.IPAddr{IP: sender.remoteIP}
 	s, err := net.DialIP("ip4:UDP", laddr, raddr)
+	if err != nil {
+		return err
+	}
 
 	f, err := s.File()
 	if err != nil {
@@ -1059,7 +1061,7 @@ func (sender *udpSenderDF) dial() error {
 
 func (sender *udpSenderDF) send(msg []byte, raddr *net.UDPAddr) error {
 	// Ensure we have a socket sending to the right IP address
-	if sender.socket == nil || !bytes.Equal(sender.remoteIP, raddr.IP) {
+	if sender.socket == nil || !sender.remoteIP.Equal(raddr.IP) {
 		sender.remoteIP = raddr.IP
 		if err := sender.dial(); err != nil {
 			return err
@@ -1111,7 +1113,7 @@ func (sender *udpSenderDF) close() error {
 }
 
 func udpAddrsEqual(a *net.UDPAddr, b *net.UDPAddr) bool {
-	return bytes.Equal(a.IP, b.IP) && a.Port == b.Port && a.Zone == b.Zone
+	return a.IP.Equal(b.IP) && a.Port == b.Port && a.Zone == b.Zone
 }
 
 func allZeros(s []byte) bool {

site/building.md

@@ -1,6 +1,7 @@
 ---
 title: Building Weave Net
 menu_order: 120
+search_type: Documentation
 ---
 You only need to build Weave Net if you want to work on the Weave Net codebase
 (or you just enjoy building software).

site/cni-plugin.md

@@ -1,6 +1,7 @@
 ---
 title: Integrating Kubernetes and Mesos via the CNI Plugin
 menu_order: 65
+search_type: Documentation
 ---
 
 > The recommended way of using Weave with Kubernetes is via the new
@@ -15,7 +16,7 @@ application containers.  CNI is supported by
 and 
 [others](https://github.com/containernetworking/cni#who-is-using-cni).
 
-###Installing the Weave Net CNI plugin
+### Installing the Weave Net CNI plugin
 
 If your machine has the directories normally used to host CNI plugins, 
 then the Weave Net CNI plugin is installed when you run `weave setup`.
@@ -29,7 +30,7 @@ Then run:
 
     weave setup
 
-####Launching Weave Net
+#### Launching Weave Net
 
 To create a network that spans multiple hosts, the Weave peers must be connected to each other.  
 This is accomplished by specifying the other hosts during `weave launch` or via
@@ -40,7 +41,7 @@ for a discussion on peer connections.
 
     weave launch <peer hosts>
 
-####Using the CNI network configuration file
+#### Using the CNI network configuration file
 
 All CNI plugins are configured by a JSON file in the directory
 `/etc/cni/net.d/`.  `weave setup` installs a minimal configuration
@@ -64,9 +65,9 @@ The following other fields in the spec are supported:
 - `ipam / subnet` - default is to use Weave's IPAM default subnet
 - `ipam / gateway` - default is to use the Weave bridge IP address (allocated by `weave expose`)
 
-###Using the Weave Net CNI plugin
+### Using the Weave Net CNI plugin
 
-####Configuring Kubernetes to use the CNI Plugin
+#### Configuring Kubernetes to use the CNI Plugin
 
 After you've launched Weave and peered your hosts, you can configure
 Kubernetes to use Weave, by adding the following options to the
@@ -79,7 +80,7 @@ for more details.
 
 Now, whenever Kubernetes starts a pod, it will be attached to the Weave network.
 
-####Configuring Mesos to use the CNI plugin
+#### Configuring Mesos to use the CNI plugin
 
 To use the CNI plugin, the Mesos Agent must be started with reference
 to the CNI configuration and binary directories:
@@ -105,7 +106,7 @@ connected to the weave network)"
 For more information, see the 
 [Mesos documentation](http://mesos.apache.org/documentation/cni/).
 
-###Caveats
+### Caveats
 
 - The Weave Net router container must be running for CNI to allocate addresses
 - The CNI plugin does not add entries to weaveDNS.

site/faq.md

@@ -1,6 +1,7 @@
 ---
 title: FAQ
 menu_order: 200
+search_type: Documentation
 ---
 
 

site/features.md

@@ -1,6 +1,7 @@
 ---
 title: Feature Overview
 menu_order: 20
+search_type: Documentation
 ---
 
  * [Virtual Ethernet Switch](#virtual-ethernet-switch)
@@ -27,7 +28,7 @@ menu_order: 20
 
 For step-by-step instructions on how to use Weave Net, see [Using Weave Net](/site/using-weave.md).
 
-###<a name="virtual-ethernet-switch"></a>Virtual Ethernet Switch
+### <a name="virtual-ethernet-switch"></a>Virtual Ethernet Switch
 
 Weave Net creates a virtual network that connects Docker containers
 deployed across multiple hosts.
@@ -46,7 +47,7 @@ over Weave Net.
 To start using Weave Net, see [Installing Weave Net](/site/installing-weave.md) 
 and [Using Weave Net](/site/using-weave.md).
 
-###<a name="fast-data-path"></a>Fast Datapath
+### <a name="fast-data-path"></a>Fast Datapath
 
 Weave Net automatically chooses the fastest available method to 
 transport data between peers. The best performing of these 
@@ -55,7 +56,7 @@ transport data between peers. The best performing of these
 See [Using Fast Datapath](/site/using-weave/fastdp.md) and
 [How Fast Datapath Works](/site/how-it-works/fastdp-how-it-works.md).
 
-###<a name="docker"></a>Seamless Docker Integration (Weave Docker API Proxy)
+### <a name="docker"></a>Seamless Docker Integration (Weave Docker API Proxy)
 
 Weave Net includes a [Docker API Proxy](/site/weave-docker-api.md), which can be 
 used to start containers using the Docker [command-line interface](https://docs.docker.com/reference/commandline/cli/) or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/), and attach them to the Weave network before they begin execution.
@@ -73,7 +74,7 @@ policy, are re-attached to the Weave network by the `Weave Docker API Proxy`.
 See [Integrating Docker via the API Proxy](/site/weave-docker-api.md).
 
 
-###<a name="plugin"></a>Weave Network Docker Plugin
+### <a name="plugin"></a>Weave Network Docker Plugin
 
 Weave Net can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
 named `weave` is created by `weave launch`, which is used as follows:
@@ -88,14 +89,14 @@ when there are network connectivity problems.
 See [Integrating Docker via the Network Plugin](/site/plugin.md) for more details.
 
 
-###<a name="cniplugin"></a>Weave Network CNI Plugin
+### <a name="cniplugin"></a>Weave Network CNI Plugin
 
 Weave can be used as a plugin to systems that support the [Container Network Interface](https://github.com/appc/cni), such as Kubernetes and Mesosphere.
 
 See [Integrating Kubernetes and Mesos via the CNI Plugin](/site/cni-plugin.md) for more details.
 
 
-###<a name="addressing"></a>IP Address Management (IPAM)
+### <a name="addressing"></a>IP Address Management (IPAM)
  
 Containers are automatically allocated a unique IP address. To view the addresses allocated by Weave, run `weave ps`.
 
@@ -106,7 +107,7 @@ For a discussion on how Weave Net uses IPAM, see [Automatic IP Address Managemen
 [the basics of IP addressing](/site/how-it-works/ip-addresses.md) for an explanation of addressing and private networks. 
 
 
-###<a name="naming-and-discovery"></a>Naming and Discovery
+### <a name="naming-and-discovery"></a>Naming and Discovery
  
 Named containers are automatically registered in [weaveDNS](/site/weavedns.md), 
 and are discoverable by using standard, simple name lookups:
@@ -119,7 +120,7 @@ WeaveDNS also supports [load balancing](/site/weavedns/load-balance-fault-weaved
 
 See [Discovering Containers with WeaveDNS](/site/weavedns.md).
  
-###<a name="application-isolation"></a>Application Isolation
+### <a name="application-isolation"></a>Application Isolation
 
 A single Weave network can host multiple, isolated 
 applications, with each application's containers being able 
@@ -136,13 +137,13 @@ See [Isolating Applications](/site/using-weave/application-isolation.md)
 for information on how to use the isolation-through-subnets 
 technique with Weave Net.
 
-###<a name="network-policy"></a>Network Policy
+### <a name="network-policy"></a>Network Policy
 
 The Weave [Kubernetes Addon](/site/kube-addon.md) includes a network
 policy controller that implements [Kubernetes Network
 Policies](http://kubernetes.io/docs/user-guide/networkpolicies/).
 
-###<a name="dynamic-network-attachment"></a>Dynamic Network Attachment
+### <a name="dynamic-network-attachment"></a>Dynamic Network Attachment
 
 At times, you may not know the application network for a 
 given container in advance. In these cases, you can take 
@@ -153,7 +154,7 @@ See [Dynamically Attaching and Detaching Containers](/site/using-weave/dynamical
 for details. 
 
 
-###<a name="security"></a>Security
+### <a name="security"></a>Security
 
 In keeping with our ease-of-use philosophy, the cryptography 
 in Weave Net is intended to satisfy a particular user requirement: 
@@ -179,14 +180,14 @@ and, additionally in the case of encrypted fast datapath using [the cryptography
 For information on how to secure your Docker network connections, see [Securing Connections Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md) and for a more technical discussion on how Weave implements encryption see, [Weave Encryption](/site/how-it-works/encryption.md) and [How Weave Implements Encryption](/site/how-it-works/encryption-implementation.md).
 
 
-###<a name="host-network-integration"></a>Host Network Integration
+### <a name="host-network-integration"></a>Host Network Integration
 
 Weave Net application networks can be integrated with a host's network, and establish connectivity between the host and 
 application containers anywhere.
 
 See [Integrating with the Host Network](/site/using-weave/host-network-integration.md).
 
-###<a name="services"></a>Managing Services: Exporting, Importing, Binding and Routing
+### <a name="services"></a>Managing Services: Exporting, Importing, Binding and Routing
  
  * **Exporting Services** - Services running in containers on a Weave network can be made accessible to the outside world or to other networks.
  * **Importing Services** - Applications can run anywhere, and yet still be made accessible by specific application containers or services.
@@ -195,7 +196,7 @@ See [Integrating with the Host Network](/site/using-weave/host-network-integrati
 
 See [Managing Services - Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md) for instructions on how to manage services on a Weave container network. 
 
-###<a name="multi-cloud-networking"></a>Multi-Cloud Networking
+### <a name="multi-cloud-networking"></a>Multi-Cloud Networking
 
 Weave can network containers hosted in different cloud providers 
 or data centers. For example, you can run an application consisting 
@@ -206,7 +207,7 @@ of containers that run on [Google Compute Engine](https://cloud.google.com/compu
 See [Enabling Multi-Cloud networking and Muti-hop Routing](/site/using-weave/multi-cloud-multi-hop.md).
 
 
-###<a name="multi-hop-routing"></a>Multi-Hop Routing
+### <a name="multi-hop-routing"></a>Multi-Hop Routing
 
 A network of containers across more than two hosts can be established 
 even when there is only partial connectivity between the hosts. Weave Net
@@ -216,14 +217,14 @@ of connected hosts between them.
 See [Enabling Multi-Cloud networking and Multi-hop Routing](/site/using-weave/multi-cloud-multi-hop.md).
 
 
-###<a name="dynamic-topologies"></a>Dynamic Topologies
+### <a name="dynamic-topologies"></a>Dynamic Topologies
 
 Hosts can be added to or removed from a Weave network without stopping
 or reconfiguring the remaining hosts. See [Adding and Removing Hosts
 Dynamically.](/site/using-weave/finding-adding-hosts-dynamically.md)
 
 
-###<a name="container-mobility"></a>Container Mobility
+### <a name="container-mobility"></a>Container Mobility
 
 Containers can be moved between hosts without requiring any 
 reconfiguration or, in many cases, restarts of other containers. 
@@ -233,7 +234,7 @@ with the same IP address as it was given originally.
 See [Managing Services - Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md), in particular, Routing Services for more information on container mobility. 
 
 
-###<a name="fault-tolerance"></a>Fault Tolerance
+### <a name="fault-tolerance"></a>Fault Tolerance
 
 Weave Net peers continually exchange topology information, and 
 monitor and (re)establish network connections to other peers. 

site/how-it-works.md

@@ -1,6 +1,7 @@
 ---
 title: Understanding how Weave Net Works
 menu_order: 90
+search_type: Documentation
 ---
 
 

site/how-it-works/encryption-implementation.md

@@ -1,6 +1,7 @@
 ---
 title: How Weave Net Implements Encryption
 menu_order: 70
+search_type: Documentation
 ---
 
 This section describes some details of Weave Net's built-in
@@ -13,7 +14,7 @@ This section describes some details of Weave Net's built-in
 
 
 
-####<a name="ephemeral-key"></a>Establishing the Ephemeral Session Key
+#### <a name="ephemeral-key"></a>Establishing the Ephemeral Session Key
 
 For every connection between peers, a fresh public/private key pair is
 created at both ends, using NaCl's `GenerateKey` function. The public
@@ -48,7 +49,7 @@ not be able to form valid ephemeral session keys.
 The same ephemeral session key is used for both TCP and UDP traffic
 between two peers.
 
-###<a name="csprng"></a> Key Generation and The Linux CSPRNG
+### <a name="csprng"></a> Key Generation and The Linux CSPRNG
 
 Generating fresh keys for every connection
 provides forward secrecy at the cost of placing a demand on the Linux
@@ -84,7 +85,7 @@ Weave Net's demand on `/dev/urandom` is causing you problems with blocking
 `/dev/random` reads, please get in touch with us - we'd love to hear
 about your use case.
 
-####<a name="tcp"></a>Encypting and Decrypting TCP Messages
+#### <a name="tcp"></a>Encypting and Decrypting TCP Messages
 
 TCP connection are only used to exchange topology information between
 peers, via a message-based protocol. Encryption of each message is
@@ -105,9 +106,9 @@ polarity. As a result the receiver will only be able to decrypt a
 message if it has the expected sequence number. This prevents replay
 attacks.
 
-####<a name="udp"></a>Encrypting and Decrypting UDP Packets
+#### <a name="udp"></a>Encrypting and Decrypting UDP Packets
 
-#####Sleeve
+##### Sleeve
 
 UDP connections carry captured traffic between peers. For a UDP packet
 sent between peers that are using crypto, the encapsulation looks as
@@ -181,7 +182,7 @@ contained in the set. The window spans at least 2^20 message sequence
 numbers, and hence any re-ordering between the most recent ~1 million
 messages is handled without dropping messages.
 
-#####Fast Datapath
+##### Fast Datapath
 
 Encryption in fastdp uses [the ESP protocol of IPsec](https://tools.ietf.org/html/rfc2406)
 in the transport mode. Each VXLAN packet is encrypted with

site/how-it-works/encryption.md

@@ -1,6 +1,7 @@
 ---
 title: Encryption and Weave Net
 menu_order: 60
+search_type: Documentation
 ---
 
 

site/how-it-works/fastdp-how-it-works.md

@@ -1,6 +1,7 @@
 ---
 title: How Fast Datapath Works
 menu_order: 30
+search_type: Documentation
 ---
 
 

site/how-it-works/ip-addresses.md

@@ -1,6 +1,7 @@
 ---
 title: IP Addresses, Routes and Networks
 menu_order: 50
+search_type: Documentation
 ---
 
 

site/how-it-works/network-topology.md

@@ -1,6 +1,7 @@
 ---
 title: How Weave Net Interprets Network Topology
 menu_order: 20
+search_type: Documentation
 ---
 
 This section contains the following topics: 
@@ -11,7 +12,7 @@ This section contains the following topics:
  * [What Happens When The Topology is Out of Date?](#out-of-date-topology)
 
 
-###<a name="topology"></a>Communicating Topology Among Peers
+### <a name="topology"></a>Communicating Topology Among Peers
 
 Topology messages capture which peers are connected to other peers. 
 Weave peers communicate their knowledge of the topology
@@ -49,7 +50,7 @@ improved update containing them is gossiped.
 If the update mentions a peer that the receiver does not know, then
 the entire update is ignored.
 
-####<a name="messages"></a>How Messages Are Formed
+#### <a name="messages"></a>How Messages Are Formed
 
 Every gossip message is structured as follows:
 
@@ -120,14 +121,14 @@ which the structure is:
     | Connection N: Established         |
     +-----------------------------------+
 
-####<a name="removing-peers"></a>Removing Peers
+#### <a name="removing-peers"></a>Removing Peers
 
 If a peer, after receiving a topology update, sees that another peer
 no longer has any connections within the network, it drops all
 knowledge of that second peer.
 
 
-####<a name="out-of-date-topology"></a>What Happens When The Topology is Out of Date?
+#### <a name="out-of-date-topology"></a>What Happens When The Topology is Out of Date?
 
 The propagation of topology changes to all peers is not instantaneous.
 Therefore, it is very possible for a node elsewhere in the network to have an

site/how-it-works/router-encapsulation.md

@@ -1,6 +1,7 @@
 ---
 title: Weave Net Router Sleeve Encapsulation
 menu_order: 10
+search_type: Documentation
 ---
 
 When the Weave Net router forwards packets to peers in `sleeve` mode

site/installing-weave.md

@@ -1,11 +1,12 @@
 ---
 title: Installing Weave Net
 menu_order: 30
+search_type: Documentation
 ---
 
 
 Ensure you are running Linux (kernel 3.8 or later) and have Docker
-(version 1.6.0 or later) installed. 
+(version 1.10.0 or later) installed.
 
 Install Weave Net by running the following:
 
@@ -20,13 +21,13 @@ After your VM is setup with Docker Machine, Weave Net can be launched directly f
 
 With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Using Weave Net](/site/using-weave.md).
 
-###Quick Start Screencast
+### Quick Start Screencast
 
 <a href="https://youtu.be/kihQCCT1ykE" target="_blank">
   <img src="hello-screencast.png" alt="Click to watch the screencast" />
 </a>
 
-###Checkpoint
+### Checkpoint
 
 Weave Net [periodically contacts Weaveworks servers for available
 versions](https://github.com/weaveworks/go-checkpoint).  New versions
@@ -45,7 +46,7 @@ To disable this check, run the following before launching Weave Net:
 
     export CHECKPOINT_DISABLE=1
 
-###Guides for Specific Platforms
+### Guides for Specific Platforms
 
 CoreOS users see [here](/guides/networking-docker-containers-with-weave-on-coreos/) for an example of installing Weave using cloud-config.
 

site/installing-weave/systemd.md

@@ -1,6 +1,7 @@
 ---
 title: Using Weave with Systemd
 menu_order: 130
+search_type: Documentation
 ---
 
 

site/introducing-weave.md

@@ -1,6 +1,7 @@
 ---
 title: Introducing Weave Net
 menu_order: 10
+search_type: Documentation
 ---
 
 
@@ -9,52 +10,52 @@ Weave Net creates a virtual network that connects Docker containers across multi
 Services provided by application containers on the weave network can be exposed to the outside world, regardless of where they are running. Similarly, existing internal systems can be opened to accept connections from application containers irrespective of their location.
 
 
-##Why Weave?
+## Why Weave?
 
-###Hassle Free Configuration
+### Hassle Free Configuration
 
 Weave Net simplifies setting up a container network. Because containers on a Weave network use standard port numbers, (for example MySQL’s default is port 3306), managing microservices is straightforward. Every container can find the IP of any other container using a simple DNS query on the container's name, and it can also communicate directly without NAT, without using port mappings or complicated ambassador linking.  And best of all deploying a Weave container network requires zero changes to your application’s code. 
 
 ![Weave Net Encapsulation](weave-net-overview.png)
 
-###Service Discovery
+### Service Discovery
 
 Weave Net implements service discovery by providing a fast "micro DNS" server at each node. You simply name containers and everything 'just works', including load balancing across multiple containers with the same name.  
 
-###No External Cluster Store Required
+### No External Cluster Store Required
 
 All other Docker networking plugins, including Docker's own "Overlay" driver, require that you set up Docker with a cluster store – a central database like Consul or Zookeeper – before you can even use them. Besides being difficult to set up, maintain and manage, every Docker host must also be in constant contact with the cluster store: if you lose the connection, even temporarily, then you cannot start or stop any containers.
 
 Weave Net is bundled with a Docker Network plugin that doesn't require an external cluster store. You can get started right away and you can start and stop containers even when there are network connectivity problems.  
 For information about the Weave Docker Plugin, see [How The Weave Network Plugin Works](/site/plugin/plugin-how-it-works.md).
 
-###Operates in Partially Connected Networks
+### Operates in Partially Connected Networks
 
 Weave Net can forward traffic between nodes, and it works even if the mesh network is only partially connected.  This means that you can have a mix of legacy systems and containerized apps and still use Weave Net to keep everything in communication. 
 
-###Weave Net is Fast
+### Weave Net is Fast
 
 Weave Net automatically chooses the fastest path between two hosts, offering near native throughput and latency, all without your intervention.  
 
 See [How Fast Datapath Works](/site/using-weave/fastdp.md) for more information.
 
-###Network Operations Friendly
+### Network Operations Friendly
 
 Weave uses industry-standard VXLAN encapsulation between hosts. This means you can continue using your favorite packet analyzing tools, such as ‘Wireshark’ to inspect and troubleshoot protocols.
 
-###Weave Net is Secure
+### Weave Net is Secure
 
 Weave Net traverses firewalls without requiring a TCP add-on. You can encrypt your traffic, which allows you to connect to apps on hosts even across an untrusted network.  
 
-###Multicast Support
+### Multicast Support
 
 Multicast addressing and routing is fully supported in Weave Net. Data can be sent to one multicast address and it will be automatically broadcast to all of its recipients. 
 
-###NAT Traversal
+### NAT Traversal
 
 With Weave Net, deploy your applications - whether peer-to-peer file sharing, voice over IP or anything else - and take advantage of built-in NAT traversal. With Weave your app is portable, containerized and with its standardized approach to networking it gives you one less thing to worry about.
 
-###Run with Anything: Kubernetes, Mesos, Amazon ECS, ...
+### Run with Anything: Kubernetes, Mesos, Amazon ECS, ...
 
 Weave Net is a good choice if you want one tool for everything.  For example: In addition to Docker plugins, you can also use Weave as a Kubernetes plugin.  You can also use Weave with Amazon ECS or with Mesos and Marathon.  
 Refer to our Getting Started and Integration Guides for more information.

site/ipam.md

@@ -1,6 +1,7 @@
 ---
 title: Allocating IP Addresses
 menu_order: 70
+search_type: Documentation
 ---
 
 
@@ -112,7 +113,7 @@ peers. This can be useful to add peers to an existing fixed cluster
 (for example in response to a scale-out event) without worrying about
 adjusting initial peer counts accordingly.
 
-####<a name="quorum"></a> `--ipalloc-init consensus=` and How Quorum is Achieved
+#### <a name="quorum"></a> `--ipalloc-init consensus=` and How Quorum is Achieved
 
 Normally it isn't a problem to over-estimate the value supplied to
 `--ipalloc-init consensus=`, but if you supply a number that is too

site/ipam/allocation-multi-ipam.md

@@ -1,6 +1,7 @@
 ---
 title: Automatic Allocation Across Multiple Subnets
 menu_order: 10
+search_type: Documentation
 ---
 
 

site/ipam/stop-remove-peers-ipam.md

@@ -1,6 +1,7 @@
 ---
 title: Starting, Stopping and Removing Peers
 menu_order: 20
+search_type: Documentation
 ---
 
 
@@ -34,7 +35,7 @@ them to be owned by host1. The name "host3" is resolved via the
 'nickname' feature of Weave Net, which defaults to the local host
 name. Alternatively, you can supply a peer name as shown in `weave status`.
 
-###<a name="caution-rmpeer"></a>Caution###
+### <a name="caution-rmpeer"></a>Caution###
 
 You cannot call `weave rmpeer` on more than one host. The address
 space, which was owned by the stale peer cannot be left dangling, and

site/ipam/troubleshooting-ipam.md

@@ -1,6 +1,7 @@
 ---
 title: Troubleshooting the IP Allocator
 menu_order: 30
+search_type: Documentation
 ---
 
 

site/kube-addon.md

@@ -1,25 +1,34 @@
 ---
 title: Integrating Kubernetes via the Addon
 menu_order: 63
+search_type: Documentation
 ---
 
 The following topics are discussed:
 
 * [Installation](#install)
-* [Network Policy Controller](#npc)
+ * [Upgrading Kubernetes to version 1.6](#kube-1.6-upgrade)
  * [Upgrading the Daemon Sets](#daemon-sets)
 * [Network Policy Controller](#npc)
  * [Troubleshooting Blocked Connections](#blocked-connections)
  * [Changing Configuration Options](#configuration-options)
 
 
-##<a name="install"></a> Installation
+## <a name="install"></a> Installation
 
 Weave Net can be installed onto your CNI-enabled Kubernetes cluster
 with a single command:
 
+* Kubernetes versions `1.6` and above:
+
 ```
-kubectl apply -f https://git.io/weave-kube
+$ kubectl apply -f https://git.io/weave-kube-1.6
+```
+
+* Kubernetes versions up to `1.5`:
+
+```
+$ kubectl apply -f https://git.io/weave-kube
 ```
 
 After a few seconds, a Weave Net pod should be running on each
@@ -51,12 +60,27 @@ Shut down Kubernetes, and _on all nodes_ perform the following:
 Then relaunch Kubernetes and install the addon as described
 above.
 
-The URL [https://git.io/weave-kube](https://git.io/weave-kube) points
-to the YAML file for the latest release of the Weave Net addon.
+The URLs [https://git.io/weave-kube](https://git.io/weave-kube) and [https://git.io/weave-kube-1.6](https://git.io/weave-kube-1.6) point
+to the YAML file for the [latest release](https://github.com/weaveworks/weave/releases/tag/latest_release) of the Weave Net addon.
 Historic versions are archived on our [GitHub release
 page](https://github.com/weaveworks/weave/releases).
 
-###<a name="daemon-sets"></a> Upgrading the Daemon Sets
+## <a name="kube-1.6-upgrade"></a> Upgrading Kubernetes to version 1.6
+
+In version 1.6, Kubernetes has increased security, so we need to
+create a special service account to run Weave Net. This is done in
+the file `weave-daemonset-k8s-1.6.yaml` attached to the [Weave Net
+release](https://github.com/weaveworks/weave/releases/latest).
+
+Also, the
+[toleration](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/taint-toleration-dedicated.md)
+required to let Weave Net run on master nodes has moved from an
+annotation to a field on the DaemonSet spec object.
+
+If you have edited the Weave Net DaemonSet from a previous release,
+you will need to re-make your changes against the new version.
+
+### <a name="daemon-sets"></a> Upgrading the Daemon Sets
 
 Kubernetes does not currently support rolling upgrades of daemon sets,
 and so you will need to perform the procedure manually:
@@ -68,7 +92,7 @@ and so you will need to perform the procedure manually:
   lose track of IP address range ownership, possibly leading to
   duplicate IP addresses if you then start a new copy of Weave Net.
 
-##<a name="npc"></a>Network Policy Controller
+## <a name="npc"></a>Network Policy Controller
 
 The addon also supports the [Kubernetes policy
 API](http://kubernetes.io/docs/user-guide/networkpolicies/) so that
@@ -86,7 +110,7 @@ definition](http://kubernetes.io/docs/api-reference/extensions/v1beta1/definitio
   all multicast traffic) by adding `--allow-mcast` as an argument to
   `weave-npc` in the YAML configuration.
 
-###<a name="blocked-connections"></a> Troubleshooting Blocked Connections
+### <a name="blocked-connections"></a> Troubleshooting Blocked Connections
 
 If you suspect that legitimate traffic is being blocked by the Weave Network Policy Controller, the first thing to do is check the `weave-npc` container's logs.
 
@@ -118,7 +142,7 @@ TCP connection from 10.32.0.7:56648 to 10.32.0.11:80 blocked by Weave NPC.
 UDP connection from 10.32.0.7:56648 to 10.32.0.11:80 blocked by Weave NPC.
 ```
 
-###<a name="configuration-options"></a> Changing Configuration Options
+### <a name="configuration-options"></a> Changing Configuration Options
 
 The default configuration settings can be changed by saving and editing the
 addon YAML before running `kubectl apply`. Additional arguments may be
@@ -138,20 +162,20 @@ inserted into the YAML file like this:
 
 The list of variables you can set is:
 
-* CHECKPOINT\_DISABLE - if set to 1, disable checking for new Weave Net
+* `CHECKPOINT_DISABLE` - if set to 1, disable checking for new Weave Net
   versions (default is blank, i.e. check is enabled)
-* IPALLOC\_RANGE - the range of IP addresses used by Weave Net
-  and the subnet they are placed in (CIDR format; default 10.32.0.0/12)
-* EXPECT\_NPC - set to 0 to disable Network Policy Controller (default is on)
-* KUBE\_PEERS - list of addresses of peers in the Kubernetes cluster
+* `IPALLOC_RANGE` - the range of IP addresses used by Weave Net
+  and the subnet they are placed in (CIDR format; default `10.32.0.0/12`)
+* `EXPECT_NPC` - set to 0 to disable Network Policy Controller (default is on)
+* `KUBE_PEERS` - list of addresses of peers in the Kubernetes cluster
   (default is to fetch the list from the api-server)
-* IPALLOC\_INIT - set the initialization mode of the [IP Address
+* `IPALLOC_INIT` - set the initialization mode of the [IP Address
   Manager](/site/operational-guide/concepts.md#ip-address-manager)
-  (defaults to consensus amongst the KUBE\_PEERS)
-* WEAVE\_EXPOSE\_IP - set the IP address used as a gateway from the
+  (defaults to consensus amongst the `KUBE_PEERS`)
+* `WEAVE_EXPOSE_IP` - set the IP address used as a gateway from the
   Weave network to the host network - this is useful if you are
   configuring the addon as a static pod.
-* WEAVE\_MTU - Weave Net defaults to 1376 bytes, but you can set a
+* `WEAVE_MTU` - Weave Net defaults to 1376 bytes, but you can set a
   smaller size if your underlying network has a tighter limit, or set
   a larger size for better performance if your network supports jumbo
   frames - see [here](/site/using-weave/fastdp.md#mtu) for more

site/metrics.md

@@ -1,6 +1,7 @@
 ---
 title: Monitoring with Prometheus
 menu_order: 105
+search_type: Documentation
 ---
 
 Two endpoints are exposed: one for the Weave Net router, and, when deployed as

site/operational-guide.md

@@ -1,6 +1,7 @@
 ---
 title: Operational Guide
 menu_order: 45
+search_type: Documentation
 ---
 This operational guide is intended to give you an overview of how to
 operate and manage a Weave Network in production. It consists of three

site/operational-guide/autoscaling.md

@@ -1,6 +1,7 @@
 ---
 title: Autoscaling
 menu_order: 40
+search_type: Documentation
 ---
 
 ### Bootstrapping

site/operational-guide/concepts.md

@@ -1,6 +1,7 @@
 ---
 title: Concepts
 menu_order: 10
+search_type: Documentation
 ---
 This section describes some of the essential concepts with which you will
 need to be familiar before continuing to the example deployment
@@ -18,18 +19,18 @@ The following concepts are described:
     * [Observers](#observers)
  * [Persistence](#persistence)
 
-##<a name="host"></a>Host
+## <a name="host"></a>Host
 
 For the purposes of this documentation a host is an
 installation of the Linux operating system that is running an
 instance of the Docker Engine. The host may be executing directly on bare
 hardware or inside a virtual machine.
 
-##<a name="peer"></a>Peer
+## <a name="peer"></a>Peer
 
 A peer is a running instance of Weave Net, typically one per host.
 
-##<a name="peer-name"></a>Peer Name
+## <a name="peer-name"></a>Peer Name
 
 Weave Net peers are identified by a 48-bit value formatted like an
 ethernet MAC address, for example, `01:23:45:67:89:ab`. The 'peer
@@ -66,14 +67,14 @@ The appropriate strategy for assigning peer names depends on the type
 and method of your particular deployment and is discussed in more
 detail below.
 
-##<a name="peer-discovery"></a>Peer Discovery
+## <a name="peer-discovery"></a>Peer Discovery
 
 Peer discovery is a mechanism that allows peers to learn about new
 Weave Net hosts from existing peers without being explicitly told. Peer
 discovery is
 [enabled by default](/site/using-weave/finding-adding-hosts-dynamically.md).
 
-##<a name="network-partition"></a>Network Partition
+## <a name="network-partition"></a>Network Partition
 
 A network partition is a transient condition whereby some arbitrary
 subsets of peers are unable to communicate with each other for the
@@ -82,7 +83,7 @@ optic line severed. Weave Net is designed to allow peers and their
 containers to make maximum safe progress under conditions of
 partition, healing automatically once the partition is over.
 
-##<a name="ip-address-manager"></a>IP Address Manager (IPAM)
+## <a name="ip-address-manager"></a>IP Address Manager (IPAM)
 
 [IPAM](/site/ipam.md) is the subsystem responsible for dividing up a
 large contiguous block of IP addresses (known as the IP allocation
@@ -116,7 +117,7 @@ scenarios:
 
 * [Uniform Dynamic Cluster](/site/operational-guide/uniform-dynamic-cluster.md)
 
-###<a name="consensus"></a>Consensus
+### <a name="consensus"></a>Consensus
 
 Alternatively, when a new network is formed for the first time, peers
 can be configured to co-ordinate amongst themselves to automatically
@@ -132,7 +133,7 @@ scenarios:
 * [Interactive Deployment](/site/operational-guide/interactive.md)
 * [Uniform Fixed Cluster](/site/operational-guide/uniform-fixed-cluster.md)
 
-###<a name="observers"></a>Observers
+### <a name="observers"></a>Observers
 
 Finally, an option is provided to start a peer as an _observer_. Such
 peers do not require a seed peer name list or an initial peer
@@ -146,7 +147,7 @@ scenarios:
 
 * [Autoscaling](/site/operational-guide/autoscaling.md)
 
-##<a name="persistence"></a>Persistence
+## <a name="persistence"></a>Persistence
 
 Certain information is remembered between launches of Weave Net (for
 example across reboots):

site/operational-guide/interactive.md

@@ -1,6 +1,7 @@
 ---
 title: Interactive Deployment
 menu_order: 20
+search_type: Documentation
 ---
 Weave Net can be launched interactively on the command line, and as 
 long as Docker is configured to start on boot, the network will survive 

site/operational-guide/tasks.md

@@ -1,6 +1,7 @@
 ---
 title: Administrative Tasks
 menu_order: 60
+search_type: Documentation
 ---
 
 The following administrative tasks are discussed: 
@@ -12,7 +13,7 @@ The following administrative tasks are discussed:
 * [Resetting Persisted Data](#reset)
 
 
-##<a name="start-on-boot"></a>Configuring Weave Net to Start Automatically on Boot
+## <a name="start-on-boot"></a>Configuring Weave Net to Start Automatically on Boot
 
 `weave launch` runs all of Weave Net's containers with a Docker restart
 policy set to `always`.  If you have launched Weave Net manually at least
@@ -23,7 +24,7 @@ If you are aiming for a non-interactive installation, use
 [systemd](/site/installing-weave/systemd.md) or a similar init system to
 launch Weave using the `--no-restart` flag after Docker has been started.
 
-##<a name="detect-reclaim-ipam"></a>Detecting and Reclaiming Lost IP Address Space
+## <a name="detect-reclaim-ipam"></a>Detecting and Reclaiming Lost IP Address Space
 
 The recommended method of removing a peer is to run `weave reset` on that
 peer before the underlying host is decommissioned or repurposed. This
@@ -56,7 +57,7 @@ range managed by peer and also identifies the names of unreachable peers. If you
 that the peer is truly gone, rather than temporarily unreachable due to a
 partition, you can reclaim their space manually.
 
-###<a name="manually-reclaim-address-space"></a>Manually Reclaiming Address Space
+### <a name="manually-reclaim-address-space"></a>Manually Reclaiming Address Space
 
 When a peer dies unexpectedly the remaining peers will consider its
 address space to be unavailable even after it has remained unreachable
@@ -70,7 +71,7 @@ command is provided to perform this task, and must
 be executed on _one_ of the remaining peers. That peer will then take
 ownership of the freed address space.
 
-##<a name="cluster-upgrade"></a>Upgrading a Cluster
+## <a name="cluster-upgrade"></a>Upgrading a Cluster
 
 Protocol versioning and feature negotiation are employed in Weave Net
 to enable incremental rolling upgrades. Each major maintains
@@ -102,7 +103,7 @@ To minimize downtime while the new script is pulling the new container images:
 there are any special caveats or deviations from the standard
 procedure.
 
-##<a name="reset"></a>Resetting Persisted Data
+## <a name="reset"></a>Resetting Persisted Data
 
 Weave Net persists information in a data volume container named
 `weavedb`. If you wish to start from a completely clean slate (for

site/operational-guide/uniform-dynamic-cluster.md

@@ -1,6 +1,7 @@
 ---
 title: Uniform Dynamic Clusters
 menu_order: 50
+search_type: Documentation
 ---
 
 A uniform dynamic cluster has the following characteristics:

site/operational-guide/uniform-fixed-cluster.md

@@ -1,6 +1,7 @@
 ---
 title: Uniform Fixed Clusters
 menu_order: 30
+search_type: Documentation
 ---
 
 This scenario describes a production deployment of a fixed number of N

site/plugin.md

@@ -1,6 +1,7 @@
 ---
 title: Integrating Docker via the Network Plugin
 menu_order: 60
+search_type: Documentation
 ---
 
  * [Launching Weave Net and Running Containers Using the Plugin](#launching)
@@ -34,7 +35,7 @@ which a helper is provided in the Weave script:
     # ping foo
 
 
-###<a name="launching"></a>Launching Weave Net and Running Containers Using the Plugin
+### <a name="launching"></a>Launching Weave Net and Running Containers Using the Plugin
 
 Just launch the Weave Net router onto each host and make a peer connection with the other hosts:
 
@@ -55,7 +56,7 @@ then run your containers using the Docker command-line:
     64 bytes from 10.32.0.2: icmp_seq=2 ttl=64 time=0.052 ms
 
 
-###<a name="multi"></a>Creating multiple Docker Networks
+### <a name="multi"></a>Creating multiple Docker Networks
 
 Docker enables you to create multiple independent networks and attach
 different sets of containers to each network. However, coordinating
@@ -79,7 +80,7 @@ Containers attached to different Docker Networks are
 [isolated through subnets](https://www.weave.works/docs/net/latest/using-weave/application-isolation/).
 
 
-###<a name="restarting"></a>Restarting the Plugin
+### <a name="restarting"></a>Restarting the Plugin
 
 The plugin, like all Weave Net components, is started with a policy of `--restart=always`, so that it is always there after a restart or reboot. If you remove this container (for example, when using `weave reset`) before removing all endpoints created using `--net=weave`, Docker may hang for a long time when it subsequently tries to re-establish communications to the plugin.
 
@@ -90,7 +91,7 @@ If you are using `systemd` with Docker 1.9, it is advised that you modify the Do
     TimeoutStartSec=0
 
 
-###<a name="configuring"></a>Configuring the Plugin
+### <a name="configuring"></a>Configuring the Plugin
 
 The plugin accepts a number of configuration parameters. To supply
 these, instead of running `weave launch`, start the router and plugin

site/plugin/plugin-how-it-works.md

@@ -1,6 +1,7 @@
 ---
 title: How the Weave Net Docker Network Plugin Works
 menu_order: 20
+search_type: Documentation
 ---
 
 

site/troubleshooting.md

@@ -1,6 +1,7 @@
 ---
 title: Troubleshooting Weave Net
 menu_order: 110
+search_type: Documentation
 ---
 
 

site/using-weave.md

@@ -1,9 +1,10 @@
 ---
 title: Using Weave Net
 menu_order: 40
+search_type: Documentation
 ---
 
-Weave Net provides a simple to deploy networking solution for containerized apps. Here, we describe how to manage a Weave container network using a sample application which consists of two simple `netcat` services deployed to containers on two separate hosts, and sometimes extended across three hosts.  
+Weave Net provides a simple to deploy networking solution for containerized apps. Here, we describe how to manage a Weave container network using a sample application which consists of two simple `netcat` services deployed to containers on two separate hosts.
 
 This section contains the following topics: 
 
@@ -13,7 +14,7 @@ This section contains the following topics:
  * [Starting the Netcat Service](#start-netcat)
 
 
-###<a name="launching"></a>Launching Weave Net
+### <a name="launching"></a>Launching Weave Net
 
 Before launching Weave Net and deploying your apps, ensure that Docker is [installed](https://docs.docker.com/engine/installation/) on both hosts. 
 
@@ -57,7 +58,7 @@ You can also preload the images by running `weave setup`. Preloaded images are u
 If you are deploying an application that consists of more than one container to the same host, launch them one after another using `docker run`, as appropriate.  
 
 
-###<a name="peer-connections"></a>Creating Peer Connections Between Hosts
+### <a name="peer-connections"></a>Creating Peer Connections Between Hosts
 
 To launch Weave Net on an additional host and create a peer connection, run the following:
 
@@ -73,7 +74,7 @@ You can also peer with other hosts by specifying the IP address, and a `:port` b
 
 There are a number of different ways that you can specify peers on a Weave network. You can launch Weave Net on `$HOST1` and then peer with `$HOST2`, or you can launch on `$HOST2` and peer with `$HOST1` or you can tell both hosts about each other at launch. The order in which peers are specified is not important. Weave Net automatically (re)connects to peers when they become available. 
 
-####Specifying Multiple Peers at Launch
+#### Specifying Multiple Peers at Launch
 
 To specify multiple peers, supply a list of addresses to which you want to connect, all separated by spaces. 
 
@@ -83,7 +84,7 @@ For example:
 
 Peers can also be dynamically added. See [Adding Hosts Dynamically](/site/using-weave/finding-adding-hosts-dynamically.md) for more information.
 
-####Restricting Access
+#### Restricting Access
 
 By default Weave Net listens on all host IPs (i.e. 0.0.0.0). This
 can be altered with the `--host` parameter to `weave launch`, for example, 
@@ -95,7 +96,7 @@ Weave Net control and data ports.
 For communication across untrusted networks, connections can be
 [encrypted](/site/using-weave/security-untrusted-networks.md).
 
-###<a name="testing"></a>Testing Container Communications
+### <a name="testing"></a>Testing Container Communications
 
 With two containers running on separate hosts, test that both containers are able to find and communicate with one another using ping. 
 
@@ -116,7 +117,7 @@ Similarly, in the container started on `$HOST2`...
     1 packets transmitted, 1 received, 0% packet loss, time 0ms
     rtt min/avg/max/mdev = 0.366/0.366/0.366/0.000 ms
 
-###<a name="start-netcat"></a>Starting the Netcat Service
+### <a name="start-netcat"></a>Starting the Netcat Service
 
 The `netcat` service can be started using the following commands:  
 

site/using-weave/application-isolation.md

@@ -1,6 +1,7 @@
 ---
 title: Isolating Applications on a Weave Network
 menu_order: 30
+search_type: Documentation
 ---
 
 A single Weave network can host multiple, isolated applications where each application's containers are able 

site/using-weave/awsvpc.md

@@ -1,6 +1,7 @@
 ---
 title: Using IP Routing on an Amazon Web Services Virtual Private Cloud
 menu_order: 110
+search_type: Documentation
 ---
 
 If your container infrastructure is running entirely within Amazon Web Services (AWS) 
@@ -16,7 +17,7 @@ on which they live.
 
 ![Weave Net AWS-VPC Mode](weave-net-awsvpc-1007x438.png)
 
-###Configuring EC2 Instances to use Weave AWS-VPC Mode
+### Configuring EC2 Instances to use Weave AWS-VPC Mode
 
 First, your AWS instances need to be given write access to the route
 table via its
@@ -59,7 +60,7 @@ addresses will flow over the AWS network unmodified.
 Finally, since Weave will be operating with IP addresses outside of the 
 range allocated by Amazon, you must disable "Source/Destination check" on each machine.
 
-###Using AWS-VPC Mode
+### Using AWS-VPC Mode
 
 Launch Weave Net with the `--awsvpc` flag:
 
@@ -68,7 +69,7 @@ Launch Weave Net with the `--awsvpc` flag:
  >>**Note:** You will still need to supply the names or IP addresses of other hosts in
 your cluster.
 
-###Present Limitations
+### Present Limitations
 
 - AWS-VPC mode does not inter-operate with other Weave Net modes; it
   is all or nothing.  In this mode, all hosts in a cluster must be AWS
@@ -85,7 +86,7 @@ your cluster.
 - All of your containers must be on the same network, with no subnet
   isolation. (We hope to ease this limitation in future.)
 
-###Packet size (MTU)
+### Packet size (MTU)
 
 The Maximum Transmission Unit, or MTU, is the technical term for the
 limit on how big a single packet can be on the network. Weave Net

site/using-weave/configuring-weave.md

@@ -1,6 +1,7 @@
 ---
 title: Allocating IPs in a Specific Range
 menu_order: 15
+search_type: Documentation
 ---
 
 The default configurations for both Weave Net and Docker use [Private

site/using-weave/dynamically-attach-containers.md

@@ -1,6 +1,7 @@
 ---
 title: Dynamically Attaching and Detaching Applications
 menu_order: 40
+search_type: Documentation
 ---
 
 
@@ -20,7 +21,7 @@ where,
 
 >Note If you are using the Weave Docker API proxy, it will have modified `DOCKER_HOST` to point to the proxy and therefore you will have to pass `-e WEAVE_CIDR=none` to start a container that _doesn't_ get automatically attached to the weave network for the purposes of this example.
 
-###Dynamically Detaching Containers
+### Dynamically Detaching Containers
 
 A container can be detached from a subnet, by using the `weave detach` command:
 

site/using-weave/fastdp.md

@@ -1,6 +1,7 @@
 ---
 title: Using Fast Datapath
 menu_order: 96
+search_type: Documentation
 ---
 
 
@@ -10,13 +11,13 @@ When Weave Net cannot use the fast data path between two hosts, it falls back to
 
 See [How Fastdp Works](/site/how-it-works/fastdp-how-it-works.md) for a more in-depth discussion of this feature. 
 
-###Disabling Fast Datapath
+### Disabling Fast Datapath
 
 You can disable fastdp by enabling the `WEAVE_NO_FASTDP` environment variable at `weave launch`:
 
     $ WEAVE_NO_FASTDP=true weave launch
 
-###Fast Datapath and Encryption
+### Fast Datapath and Encryption
 
 Fast datapath implements encryption using IPsec which is configured with IP
 transformation framework (XFRM) provided by the Linux kernel.
@@ -28,7 +29,7 @@ Cloud Platform denies ESP packets by default.
 See [How Weave Implements Encryption](/site/how-it-works/encryption-implementation.md)
 for more details for the fastdp encryption.
 
-###Viewing Connection Mode Fastdp or Sleeve
+### Viewing Connection Mode Fastdp or Sleeve
 
 Weave Net automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave Net can use the fast datapath:
 
@@ -48,7 +49,7 @@ Where fastdp indicates that fast datapath is being used on a connection. If fast
     $ weave status connections
     <- 192.168.122.25:54782  established sleeve 8a:50:4c:23:11:ae(ubuntu1204)
 
-###<a name="mtu"></a>Packet size (MTU)
+### <a name="mtu"></a>Packet size (MTU)
 
 The Maximum Transmission Unit, or MTU, is the technical term for the
 limit on how big a single packet can be on the network. Weave Net

site/using-weave/finding-adding-hosts-dynamically.md

@@ -1,6 +1,7 @@
 ---
 title: Adding and Removing Hosts Dynamically
 menu_order: 90
+search_type: Documentation
 ---
 
 To add a host to an existing Weave network, launch Weave Net on the
@@ -23,7 +24,7 @@ hosts run:
 Any other existing hosts on the Weave network will attempt to
 establish connections to the new host as well.
 
-###Instructing Peers to Forget a Host
+### Instructing Peers to Forget a Host
 
 To instruct a peer to forget a particular host specified to it via
 `weave launch` or `weave connect` run:
@@ -34,14 +35,14 @@ This prevents the peer from reconnecting to that host once
 connectivity to it is lost, and can be used to administratively remove
 any decommissioned peers from the network.
 
-###Bulk Replacing Hosts
+### Bulk Replacing Hosts
 
 Hosts can also be bulk-replaced. All existing hosts will be forgotten,
 and the new hosts added:
 
     host# weave connect --replace $NEW_HOST1 $NEW_HOST2
 
-###Restarting Docker and Weave Net
+### Restarting Docker and Weave Net
 
 If Weave Net is restarted by Docker it automatically remembers any
 previous connect and forget operations, however if you stop it

site/using-weave/host-network-integration.md

@@ -1,6 +1,7 @@
 ---
 title: Integrating with the Host Network
 menu_order: 60
+search_type: Documentation
 ---
 
 Weave application networks can be integrated with an external host network, establishing connectivity between the host and with application containers running anywhere.
@@ -22,7 +23,7 @@ And you can also ping the `a1` netcat application container residing on `$HOST1`
 
     host2$ ping $(weave dns-lookup a1)
 
-###Exposing Multiple Subnets
+### Exposing Multiple Subnets
 
 Multiple subnet addresses can be exposed or hidden using a single command:
 
@@ -31,14 +32,14 @@ Multiple subnet addresses can be exposed or hidden using a single command:
     host2$ weave hide   net:default net:10.2.2.0/24
     10.2.1.132 10.2.2.130
 
-###Adding Exposed Addresses to weaveDNS
+### Adding Exposed Addresses to weaveDNS
 
 Exposed addresses can also be added to weaveDNS by supplying fully qualified domain names:
 
     host2$ weave expose -h exposed.weave.local
     10.2.1.132
 
-###<a name="routing"></a>Routing from Another Host
+### <a name="routing"></a>Routing from Another Host
 
 After running `weave expose`, you can use Linux routing to provide
 access to the Weave network from hosts that are not running Weave Net:

site/using-weave/manual-ip-address.md

@@ -1,6 +1,7 @@
 ---
 title: Manually Specifying the IP Address of a Container
 menu_order: 20
+search_type: Documentation
 ---
 
 Containers are automatically allocated an IP address that is unique across the Weave network. You can see which address was allocated by running, [`weave ps`](/site/troubleshooting.md#weave-status):

site/using-weave/multi-cloud-multi-hop.md

@@ -1,10 +1,11 @@
 ---
 title: Enabling Multi-Cloud, Multi-Hop Networking and Routing
 menu_order: 100
+search_type: Documentation
 ---
 
 
-###Enabling Multi-Cloud Networking
+### Enabling Multi-Cloud Networking
 
 Before multi-cloud networking can be enabled, you must configure the network to allow 
 connections through Weave Net's control and data ports on the Docker hosts. By default, the 
@@ -20,7 +21,7 @@ port and UDP 9000/9001 for its data port.
 the same setting.
 
 
-###Multi-hop routing
+### Multi-hop routing
 
 A network of containers across more than two hosts can be 
 established even when there is only partial connectivity 

site/using-weave/security-untrusted-networks.md

@@ -1,6 +1,7 @@
 ---
 title: Securing Connections Across Untrusted Networks
 menu_order: 80
+search_type: Documentation
 ---
 
 
@@ -15,23 +16,21 @@ or
     host1$ export WEAVE_PASSWORD=wfvAwt7sj
     host1$ weave launch
 
->**NOTE**: The command line option takes precedence over the environment variable._
+>**NOTE**: The command line option takes precedence over the environment variable.
 
 > To avoid leaking your password via the kernel process table or your
 > shell history, we recommend you store it in a file and capture it
 > in a shell variable prior to launching weave: `export
 > WEAVE_PASSWORD=$(cat /path/to/password-file)`
 
-To guard against dictionary attacks, the password needs to be reasonably strong with at least 50 bits of entropy is recommended. An easy way to generate a random password that satisfies this requirement is:
+To guard against dictionary attacks, the password needs to be reasonably strong,
+with at least 50 bits of entropy. An easy way to generate a random password that
+satisfies this requirement is:
 
     < /dev/urandom tr -dc A-Za-z0-9 | head -c9 ; echo
 
 The same password must be specified for all Weave Net peers, by default both control and data plane traffic will then use authenticated encryption. 
 
-[Fast datapath](/site/using-weave/fastdp.md) does not support
-encryption. If you supply a password at `weave launch`, Weave Net
-falls back to the slower `sleeve` mode for encrypted communication.
-
 As an optimization, you can selectively disable data plane encryption
 if some of your peers are co-located in a trusted network, for example
 within the boundary of your own data center. List these networks using
@@ -40,9 +39,8 @@ the `--trusted-subnets` argument with `weave launch`:
     weave launch --password wfvAwt7sj --trusted-subnets 10.0.2.0/24,192.168.48.0/24
 
 If *both* peers at the end of a connection consider the other to be in
-a trusted subnet, Weave Net attempts to establish fast datapath
-connectivity, which is unencrypted. Otherwise communication is encrypted which
-imposes overheads.
+the same trusted subnet, Weave Net attempts to establish non-encrypted
+connectivity. Otherwise communication is encrypted which imposes overheads.
 
 Configured trusted subnets are shown in [`weave status`](/site/troubleshooting.md#weave-status).
 

site/using-weave/service-management.md

@@ -1,6 +1,7 @@
 ---
 title: Managing Services - Exporting, Importing, Binding and Routing
 menu_order: 70
+search_type: Documentation
 ---
 
 This section contains the following topics: 
@@ -13,7 +14,7 @@ This section contains the following topics:
 
 
 
-###<a name="exporting"></a>Exporting Services
+### <a name="exporting"></a>Exporting Services
 
 Services running in containers on a Weave network can be made
 accessible to the outside world (and, more generally, to other networks)
@@ -43,7 +44,7 @@ With the above in place, you can connect to the 'nc' service from anywhere using
 
 Similar NAT rules to the above can be used to expose services not just to the outside world but also to other, internal, networks.
 
-###<a name="importing"></a>Importing Services
+### <a name="importing"></a>Importing Services
 
 Applications running in containers on a Weave network can be given access to services, which are only reachable from certain 
 Weave hosts, regardless of where the actual application containers are located.
@@ -73,7 +74,7 @@ You can now connect to it from the application container running on `$HOST2` usi
 
 Note that you should be able to run this command from any application container.
 
-###<a name="binding"></a>Binding Services
+### <a name="binding"></a>Binding Services
 
 Importing a service provides a degree of indirection that allows late and dynamic binding, similar to what can be achieved with a proxy. 
 
@@ -81,7 +82,7 @@ Referring back to the [netcat services example that is running on three hosts](#
 
 You can point application containers to another service location by changing the above NAT rule, without altering the applications.
 
-###<a name="routing"></a>Routing Services
+### <a name="routing"></a>Routing Services
 
 You can combine the service export and service import features to establish connectivity between applications and services residing on disjointed networks, even if those networks are separated by firewalls and have overlapping IP ranges. 
 
@@ -103,7 +104,7 @@ Now any host on the same network as `$HOST2` is able to access the service:
 
     echo 'Hello, world.' | nc $HOST2 4433
 
-###<a name="change-location"></a>Dynamically Changing Service Locations
+### <a name="change-location"></a>Dynamically Changing Service Locations
 
 Furthermore, as explained in Binding Services, service locations can be dynamically altered without having to change any of the applications that access them.  
 

site/weave-docker-api.md

@@ -1,6 +1,7 @@
 ---
 title: Integrating Docker via the API Proxy
 menu_order: 50
+search_type: Documentation
 ---
 
 The Docker API proxy automatically attaches containers to the Weave
@@ -9,7 +10,7 @@ network when they are started using the ordinary Docker
 or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/),
 instead of `weave run`.
 
-###<a name="attaching-containers"></a>Attaching Containers to a Weave Network
+### <a name="attaching-containers"></a>Attaching Containers to a Weave Network
 
 There are three ways to attach containers to a Weave network (which method to use is 
 entirely up to you):
@@ -34,7 +35,7 @@ See [Integrating Docker via the Network Plugin](/site/plugin.md).
 does not use the Weave Docker API Proxy. 
 See [Launching Containers With Weave Run (without the Proxy)](/site/weave-docker-api/launching-without-proxy.md). 
 
-###<a name="weave-api-proxy"></a>Setting Up The Weave Net Docker API Proxy
+### <a name="weave-api-proxy"></a>Setting Up The Weave Net Docker API Proxy
 
 The proxy sits between the Docker client (command line or API) and the
 Docker daemon, and intercepts the communication between the two. You can

site/weave-docker-api/automatic-discovery-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Using Automatic Discovery With the Weave Net Proxy
 menu_order: 30
+search_type: Documentation
 ---
 
 Containers launched via the proxy use [weaveDNS](/site/weavedns.md)

site/weave-docker-api/ipam-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Automatic IP Allocation and the Weave Proxy
 menu_order: 25
+search_type: Documentation
 ---
 
 
@@ -19,7 +20,7 @@ To start a container without connecting it to the Weave network, pass
 
     host1$ docker run -ti -e WEAVE_CIDR=none weaveworks/ubuntu
 
-###Disabling Automatic IP Address Allocation
+### Disabling Automatic IP Address Allocation
 
 If you do not want an IP to be assigned by default, the proxy needs to
 be passed the `--no-default-ipalloc` flag, for example:

site/weave-docker-api/launching-without-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Launching Containers With Weave Run (without the Proxy)
 menu_order: 50
+search_type: Documentation
 ---
 
 

site/weave-docker-api/name-resolution-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Name resolution via `/etc/hosts`
 menu_order: 40
+search_type: Documentation
 ---
 
 

site/weave-docker-api/securing-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Securing the Docker Communications With TLS
 menu_order: 20
+search_type: Documentation
 ---
 
 If you are [connecting to the docker daemon with

site/weave-docker-api/troubleshooting-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Troubleshooting
 menu_order: 60
+search_type: Documentation
 ---
 
 The command

site/weave-docker-api/using-proxy.md

@@ -1,6 +1,7 @@
 ---
 title: Using The Weave Docker API Proxy
 menu_order: 10
+search_type: Documentation
 ---
 
 
@@ -12,7 +13,7 @@ When they are started via the Weave Net proxy, containers are
 [automatically assigned IP addresses](/site/ipam.md) and connected to the
 Weave network.  
 
-###Creating and Starting Containers with the Weave Net Proxy
+### Creating and Starting Containers with the Weave Net Proxy
 
 To create and start a container via the Weave Net proxy run:
 
@@ -33,7 +34,7 @@ variable by space-separating them, as in
 `WEAVE_CIDR="10.2.1.1/24 10.2.2.1/24"`.
 
 
-###Returning Weave Network Settings Instead of Docker Network Settings
+### Returning Weave Network Settings Instead of Docker Network Settings
 
 The Docker NetworkSettings (including IP address, MacAddress, and
 IPPrefixLen), are still returned when `docker inspect` is run. If you want
@@ -46,13 +47,13 @@ only includes one of them.
 
     host1$ weave launch-router && weave launch-proxy --rewrite-inspect
 
-###Multicast Traffic and Launching the Weave Proxy
+### Multicast Traffic and Launching the Weave Proxy
 
 By default, multicast traffic is routed over the Weave network.
 To turn this off, for example, because you want to configure your own multicast
 route, add the `--no-multicast-route` flag to `weave launch-proxy`.
 
-###Other Weave Proxy options
+### Other Weave Proxy options
 
  * `--without-dns` -- stop telling containers to use [WeaveDNS](/site/weavedns.md)
  * `--log-level=debug|info|warning|error` -- controls how much

site/weavedns.md

@@ -1,6 +1,7 @@
 ---
 title: Discovering Containers with WeaveDNS
 menu_order: 80
+search_type: Documentation
 ---
 
 

site/weavedns/how-works-weavedns.md

@@ -1,6 +1,7 @@
 ---
 title: How Weave Finds Containers
 menu_order: 10
+search_type: Documentation
 ---
 
 
@@ -21,7 +22,7 @@ When weaveDNS is queried for a name in a domain other than
 `.weave.local`, it queries the host's configured nameserver, which is
 the standard behaviour for Docker containers.
 
-###Specifying a Different Docker Bridge Device
+### Specifying a Different Docker Bridge Device
 
 So that containers can connect to a stable and always routable IP
 address, weaveDNS listens on port 53 to the Docker bridge device, which

site/weavedns/load-balance-fault-weavedns.md

@@ -1,6 +1,7 @@
 ---
 title: Load Balancing and Fault Resilience with weaveDNS
 menu_order: 20
+search_type: Documentation
 ---
 
 

site/weavedns/managing-domains-weavedns.md

@@ -1,6 +1,7 @@
 ---
 title: Managing Domains
 menu_order: 30
+search_type: Documentation
 ---
 
 The following topics are discussed:
@@ -44,6 +45,6 @@ link-local as per [RFC6762](https://tools.ietf.org/html/rfc6762),
 (though this is not strictly necessary).
 
 
- * [How Weave Finds Containers](/site/how-works-weavedns.md.md)
+ * [How Weave Finds Containers](/site/how-works-weavedns.md)
  * [Load Balancing and Fault Resilience with WeaveDNS](/site/weavedns/load-balance-fault-weavedns.md)
  * [Managing Domain Entries](/site/weavedns/managing-entries-weavedns.md)

site/weavedns/managing-entries-weavedns.md

@@ -1,6 +1,7 @@
 ---
 title: Managing Domain Entries
 menu_order: 40
+search_type: Documentation
 ---
 
 

site/weavedns/troubleshooting-weavedns.md

@@ -1,6 +1,7 @@
 ---
 title: Troubleshooting and Present Limitations
 menu_order: 50
+search_type: Documentation
 ---
 
 

test/830_cni_plugin_test.sh

@@ -7,7 +7,7 @@ start_suite "Test CNI plugin"
 cni_connect() {
     pid=$(container_pid $1 $2)
     id=$(docker_on $1 inspect -f '{{.Id}}' $2)
-    run_on $1 sudo CNI_VERSION=1 CNI_COMMAND=ADD CNI_CONTAINERID=$id CNI_IFNAME=eth0 \
+    run_on $1 sudo CNI_COMMAND=ADD CNI_CONTAINERID=$id CNI_IFNAME=eth0 \
     CNI_NETNS=/proc/$pid/ns/net CNI_PATH=/opt/cni/bin /opt/cni/bin/weave-net 
 }
 
@@ -16,11 +16,23 @@ run_on $HOST1 sudo mkdir -p /opt/cni/bin
 weave_on $HOST1 setup-cni
 weave_on $HOST1 launch
 
+C0=$(docker_on $HOST1 run --net=none --name=c0 -dt $SMALL_IMAGE /bin/sh)
 C1=$(docker_on $HOST1 run --net=none --privileged --name=c1 -dt $SMALL_IMAGE /bin/sh)
 C2=$(docker_on $HOST1 run --net=none --name=c2 -dt $SMALL_IMAGE /bin/sh)
 # Enable unsolicited ARPs so that ping after the address reuse does not time out
 exec_on $HOST1 c1 sysctl -w net.ipv4.conf.all.arp_accept=1
 
+# Contrived example to trigger the bug in #2839
+cni_connect $HOST1 c0 <<EOF
+{
+    "name": "weave",
+    "type": "weave-net",
+    "ipam": {
+        "type": "weave-ipam"
+    }
+}
+EOF
+
 cni_connect $HOST1 c1 <<EOF
 {
     "name": "weave",
@@ -30,6 +42,7 @@ EOF
 
 cni_connect $HOST1 c2 <<EOF
 {
+    "cniVersion": "0.3.0",
     "name": "weave",
     "type": "weave-net",
     "ipam": {
@@ -39,9 +52,16 @@ cni_connect $HOST1 c2 <<EOF
 }
 EOF
 
+C0IP=$(container_ip $HOST1 c0)
 C1IP=$(container_ip $HOST1 c1)
 C2IP=$(container_ip $HOST1 c2)
 
+# Check the bridge IP is different from the container IPs
+BRIP=$(container_ip $HOST1 weave:expose)
+assert_raises "[ $BRIP != $C0IP ]"
+assert_raises "[ $BRIP != $C1IP ]"
+assert_raises "[ $BRIP != $C2IP ]"
+
 assert_raises "exec_on $HOST1 c1 $PING $C2IP"
 assert_raises "exec_on $HOST1 c2 $PING $C1IP"
 # Check if the route to the outside world works
@@ -62,6 +82,7 @@ C3IP=$(container_ip $HOST1 c3)
 
 # CNI shouldn't re-use the address until we call DEL
 assert_raises "[ $C2IP != $C3IP ]"
+assert_raises "[ $BRIP != $C3IP ]"
 assert_raises "exec_on $HOST1 c1 $PING $C3IP"
 
 

test/840_weave_kube_3_test.sh

@@ -20,7 +20,15 @@ SUCCESS="6 established"
 
 tear_down_kubeadm
 
-run_on $HOST1 "sudo systemctl start kubelet && sudo kubeadm init --token=$TOKEN"
+# Make an ipset, so we can check it doesn't get wiped out by Weave Net
+docker_on $HOST1 run --rm --privileged --net=host --entrypoint=/usr/sbin/ipset weaveworks/weave-npc create test_840_ipset bitmap:ip range 192.168.1.0/24 || true
+docker_on $HOST1 run --rm --privileged --net=host --entrypoint=/usr/sbin/ipset weaveworks/weave-npc add test_840_ipset 192.168.1.11
+
+# kubeadm init upgrades to latest Kubernetes version by default, therefore we try to lock the version using the below option:
+k8s_version="$(run_on $HOST1 "kubelet --version" | grep -oP "(?<=Kubernetes )v[\d\.\-beta]+")"
+k8s_version_option="$([[ "$k8s_version" > "v1.6" ]] && echo "kubernetes-version" || echo "use-kubernetes-version")"
+
+run_on $HOST1 "sudo systemctl start kubelet && sudo kubeadm init --$k8s_version_option=$k8s_version --token=$TOKEN"
 run_on $HOST2 "sudo systemctl start kubelet && sudo kubeadm join --token=$TOKEN $HOST1IP"
 run_on $HOST3 "sudo systemctl start kubelet && sudo kubeadm join --token=$TOKEN $HOST1IP"
 
@@ -52,6 +60,11 @@ assert_raises "run_on $HOST1 $PING $HOST2EXPIP"
 assert_raises "run_on $HOST2 $PING $HOST1EXPIP"
 assert_raises "run_on $HOST3 $PING $HOST2EXPIP"
 
+# Ensure we do not generate any defunct process (e.g. launch.sh) after starting weaver:
+assert "run_on $HOST1 ps aux | grep -c '[d]efunct'" "0"
+assert "run_on $HOST2 ps aux | grep -c '[d]efunct'" "0"
+assert "run_on $HOST3 ps aux | grep -c '[d]efunct'" "0"
+
 # See if we can get some pods running that connect to the network
 run_on $HOST1 "kubectl run hello --image=weaveworks/hello-world --replicas=3"
 
@@ -71,4 +84,7 @@ assert_raises wait_for_pods
 
 tear_down_kubeadm
 
+# Destroy our test ipset, and implicitly check it is still there
+assert_raises "docker_on $HOST1 run --rm --privileged --net=host --entrypoint=/usr/sbin/ipset weaveworks/weave-npc destroy test_840_ipset"
+
 end_suite

test/README.md

@@ -2,7 +2,7 @@ This directory contains integration tests for weave.
 
 ## Requirements
 
-You need three VMs with `docker` (`>=1.6.0`) installed and listening on TCP
+You need three VMs with `docker` (`>=1.10.0`) installed and listening on TCP
 port `2375` (see below). You also need to be able to SSH to these VMs without 
 having to input anything.
 

test/config.sh

@@ -274,11 +274,21 @@ start_suite() {
         PLUGIN_FILTER=$(docker_on $host inspect -f 'grep -v {{printf "%.12s" .Id}}' weaveplugin 2>/dev/null) || PLUGIN_FILTER=cat
         rm_containers $host $(docker_on $host ps -aq 2>/dev/null | $PLUGIN_FILTER)
         weave_on $host reset 2>/dev/null
+        run_on $host sudo rm -f /opt/cni/bin/weave-plugin-latest /opt/cni/bin/weave-net /opt/cni/bin/weave-ipam /etc/cni/net.d/10-weave.conf
     done
     whitely echo "$@"
 }
 
+# Common postconditions to assert on each host, after each test:
+assert_common_postconditions() {
+    # Ensure we do not generate any defunct (a.k.a. zombie) process:
+    assert "run_on $1 ps aux | grep -c '[d]efunct'" "0"
+}
+
 end_suite() {
+    for host in $HOSTS; do
+        assert_common_postconditions "$host"
+    done
     whitely assert_end
     for host in $HOSTS; do
         stop_weave_on $host

test/run-integration-tests.sh

@@ -65,7 +65,7 @@ function print_vars() {
 }
 
 function verify_dependencies() {
-    local deps=(python terraform ansible-playbook)
+    local deps=(python terraform ansible-playbook gcloud)
     for dep in "${deps[@]}"; do
         if [ ! "$(which "$dep")" ]; then
             echo >&2 "$dep is not installed or not in PATH."
@@ -157,7 +157,8 @@ function create_image() {
         terraform destroy -force "$DIR/../tools/provisioning/gcp"
         rm terraform.tfstate*
         echo
-        greenly echo "> Created GCP image $IMAGE_NAME in $(date -u -d @$(($(date +%s) - begin_img)) +"%T")."
+        local end_img=$(date +%s)
+        greenly echo "> Created GCP image $IMAGE_NAME in $(date -u -d @$((end_img - begin_img)) +"%T")."
     else
         wait_for_image
     fi
@@ -261,7 +262,8 @@ function provision() {
     esac
     [ "$1" == "on" ] && set_hosts
     echo
-    greenly echo "> Provisioning took $(date -u -d @$(($(date +%s) - begin_prov)) +"%T")."
+    local end_prov=$(date +%s)
+    greenly echo "> Provisioning took $(date -u -d @$((end_prov - begin_prov)) +"%T")."
 }
 
 function configure_with_ansible() {
@@ -290,7 +292,8 @@ function configure() {
         done
 
         echo
-        greenly echo "> Configuration took $(date -u -d @$(($(date +%s) - begin_conf)) +"%T")."
+        local end_conf=$(date +%s)
+        greenly echo "> Configuration took $(date -u -d @$((end_conf - begin_conf)) +"%T")."
     fi
 }
 
@@ -303,13 +306,16 @@ function run_tests() {
     "$DIR/run_all.sh" "$@"
     local status=$?
     echo
-    greenly echo "> Tests took $(date -u -d @$(($(date +%s) - begin_tests)) +"%T")."
+    local end_tests=$(date +%s)
+    greenly echo "> Tests took $(date -u -d @$((end_tests - begin_tests)) +"%T")."
     return $status
 }
 
+# shellcheck disable=SC2155
 function end() {
     echo
-    echo "> Build took $(date -u -d @$(($(date +%s) - begin)) +"%T")."
+    local end_time=$(date +%s)
+    echo "> Build took $(date -u -d @$((end_time - begin)) +"%T")."
 }
 
 function echo_export_hosts() {