Fix spelling mistakes.

docs/fastdp.md

@@ -24,7 +24,7 @@ The router relies on having access to the source and destination peer
 when deciding how to forward packets. When the Sleeve overlay is in
 use this information is conveyed directly within the encapsulation by
 including the names of the peers in question, a solution not
-accomodated directly by the vxlan wire format. Fortunately vxlan does
+accommodated directly by the vxlan wire format. Fortunately vxlan does
 have a twenty four bit segment ID field in the header we can use to
 encode this data - the challenge is to identify peers uniquely with a
 twelve bit identifier instead of the seventeen bytes used by Sleeve.
@@ -54,8 +54,8 @@ with low path MTUs.
 To avoid triggering this fallback in typical deployments, the datapath
 interface is statically configured with an MTU of 1410 bytes allowing
 it to work with most underlay network provider MTUs, including GCE at
-1460 bytes (the fifty byte difference accomodates the vxlan overhead).
-This value can be overriden by setting `WEAVE_MTU` at launch if
+1460 bytes (the fifty byte difference accommodates the vxlan overhead).
+This value can be overridden by setting `WEAVE_MTU` at launch if
 necessary.
 
 # Virtual Ports

docs/weavedns-design.md

@@ -9,7 +9,7 @@ The model is that each host has a service that is notified of
 hostnames and weave addresses for containers on the host.  Like IPAM,
 this service is embedded within the router.  It binds to
 the host bridge to answer DNS queries from local containers; for
-anything it can't answer, it uses the infomation in the host's
+anything it can't answer, it uses the information in the host's
 /etc/resolv.conf to query an 'fallback' server.
 
 The service is comprised of a DNS server, which answers all DNS queries
@@ -33,7 +33,7 @@ are re-broadcast around the cluster.
 The DNS server also listens to the Docker event stream, and removes
 entries for containers when they die.  Entries removed in this way are
 tombstoned, and the tombstone lazily broadcast around the cluster.
-After a short timeout the tombstones are independantly removed from
+After a short timeout the tombstones are independently removed from
 each host.
 
 

ipam/allocator.go

@@ -381,7 +381,7 @@ func (alloc *Allocator) Shutdown() {
 
 // AdminTakeoverRanges (Sync) - take over the ranges owned by a given
 // peer, and return how much space was transferred in the process.
-// Only done on adminstrator command.
+// Only done on administrator command.
 func (alloc *Allocator) AdminTakeoverRanges(peerNameOrNickname string) address.Count {
 	resultChan := make(chan address.Count)
 	alloc.actionChan <- func() {

site/ip-addresses/configuring-weave.md

@@ -20,10 +20,10 @@ appears:
 As the message indicates, the default range that Weave Net would like to use is
 `10.32.0.0/12` - a 12-bit prefix, where all addresses start with the bit
 pattern 000010100010, or in decimal everything from 10.32.0.0 through
-10.47.255.255. 
+10.47.255.255.
 
 However, your host is using a route for `10.0.0.0/8`,
-which overlaps, since the first 8 bits are the same. In this case, if you used the default network 
+which overlaps, since the first 8 bits are the same. In this case, if you used the default network
 for an address like `10.32.5.6` the kernel would never be sure if this meant the
 Weave Net network of `10.32.0.0/12` or the hosting network of
 `10.0.0.0/8`.
@@ -32,11 +32,11 @@ If you are sure the addresses you want are not in use, then
 explicitly setting the range with `--ipalloc-range` in the
 command-line arguments to `weave launch` on all hosts forces Weave
 Net to use that range, even though it overlaps. Otherwise, you can
-pick a different range, preferrably another subset of the [Private
+pick a different range, preferably another subset of the [Private
 Networks](https://en.wikipedia.org/wiki/Private_network).  For example
 172.30.0.0/16.
 
 
 **See Also**
 
- * [IP Addresses, Routes and Networks](/site/ip-addresses/ip-addresses.md)
+ * [IP Addresses, Routes and Networks](/site/ip-addresses/ip-addresses.md)

site/ipam/overview-init-ipam.md

@@ -6,19 +6,19 @@ layout: default
 
 Weave Net automatically assigns containers a unique IP address
 across the network, and also releases that address when the container
-exits. Unless you explicitly specify an address, this occurs for all 
+exits. Unless you explicitly specify an address, this occurs for all
 invocations of the `run`, `start`,
 `attach`, `detach`, `expose`, and `hide` commands. Weave Net can also assign
 addresses in multiple subnets.
 
-The following automatic IP address managment topics are discussed: 
+The following automatic IP address management topics are discussed:
 
  * [Initializing Peers on a Weave Network](#initialization)
  * [`--init-peer-count` and How Quorum is Achieved](#quorum)
  * [Forcing Consensus](#forcing-consensus)
  * [Choosing an Allocation Range](#range)
 
- 
+
 
 ### <a name="initialization"></a>Initializing Peers on a Weave Network
 
@@ -56,7 +56,7 @@ Just once, when the first automatic IP address allocation is requested
 in the whole network, Weave Net needs a majority of peers to be present in
 order to avoid formation of isolated groups, which can lead to
 inconsistency, for example, the same IP address being allocated to two
-different containers. 
+different containers.
 
 Therefore, you must either supply the list of all peers in the network at `weave launch` or add the
 `--init-peer-count` flag to specify how many peers there will be.
@@ -108,10 +108,10 @@ Normally it isn't a problem to over-estimate `--init-peer-count`, but if you sup
 a number that is too small, then multiple independent groups may form.
 
 Weave Net uses the estimate of the number of peers at initialization to
-compute a majority or quorum number - specifically floor(n/2) + 1. 
+compute a majority or quorum number - specifically floor(n/2) + 1.
 
 If the actual number of peers is less than half the number stated, then
-they keep waiting for someone else to join in order to reach a quorum. 
+they keep waiting for someone else to join in order to reach a quorum.
 
 But if the actual number is more than twice the quorum
 number, then you may end up with two sets of peers with each reaching a quorum and
@@ -123,7 +123,7 @@ definitely possible.
 The quorum number is only used once at start-up (specifically, the
 first time someone tries to allocate or claim an IP address). Once
 a set of peers is initialized, you can add more and they will join on
-to the data structure used by the existing set.  
+to the data structure used by the existing set.
 
 The one issue to watch is if the earlier peers are restarted, you must restart
 them using the current number of peers. If they use the smaller number
@@ -175,10 +175,10 @@ according to their needs.  If a group of peers becomes isolated from
 the rest (a partition), they can continue to work with the address
 ranges they had before isolation, and can subsequently be re-connected
 to the rest of the network without any conflicts arising.
-    
+
  **See Also**
 
  * [Automatic Allocation Across Multiple Subnets](/site/ipam/allocation-multi-ipam.md)
  * [Plugin Command-line Arguments](/site/plugin/plug-in-command-line.md)
- 
-    
+
+

site/troubleshooting.md

@@ -89,7 +89,7 @@ communication protocol name and supported versions (min..max).
  * **Name** - identifies the local Weave Router as a peer on the
 Weave network. The nickname shown in parentheses defaults to the name
 of the host on which the Weave container was launched. It
-can be overriden by using the `--nickname` argument at `weave
+can be overridden by using the `--nickname` argument at `weave
 launch`.
 
  * **Encryption** - indicates whether

site/weave-docker-api/set-up-proxy.md

@@ -10,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`.
 
- 
+
 ###Setting Up The Weave Net Docker API Proxy
 
 The proxy sits between the Docker client (command line or API) and the
@@ -23,7 +23,7 @@ or independently via `launch-proxy`:
 
     host1$ weave launch-router && weave launch-proxy
 
-The first form is more convenient. But only `launch-proxy` can be passed configuration arguments. 
+The first form is more convenient. But only `launch-proxy` can be passed configuration arguments.
 Therefor if you need to modify the default behaviour of the proxy, you must use `launch-proxy`.
 
 By default, the proxy decides where to listen based on how the
@@ -36,11 +36,11 @@ argument, for example:
     host1$ weave launch-proxy -H tcp://127.0.0.1:9999
 
 If no TLS or listening interfaces are set, TLS is autoconfigured
-based on the Docker daemon's settings, and the listening interfaces are 
+based on the Docker daemon's settings, and the listening interfaces are
 autoconfigured based on your Docker client's settings.
 
 Multiple `-H` arguments can be specified. If you are working with a
-remote docker daemon, then any firewalls inbetween need to be
+remote docker daemon, then any firewalls in between need to be
 configured to permit access to the proxy port.
 
 All docker commands can be run via the proxy, so it is safe to adjust

site/weavedns-design.md

@@ -9,7 +9,7 @@ The model is that each host has a service that is notified of
 hostnames and weave addresses for containers on the host.  Like IPAM,
 this service is embedded within the router.  It binds to
 the host bridge to answer DNS queries from local containers; for
-anything it can't answer, it uses the infomation in the host's
+anything it can't answer, it uses the information in the host's
 /etc/resolv.conf to query an 'fallback' server.
 
 The service is comprised of a DNS server, which answers all DNS queries
@@ -33,7 +33,7 @@ are re-broadcast around the cluster.
 The DNS server also listens to the Docker event stream, and removes
 entries for containers when they die.  Entries removed in this way are
 tombstoned, and the tombstone lazily broadcast around the cluster.
-After a short timeout the tombstones are independantly removed from
+After a short timeout the tombstones are independently removed from
 each host.