From 7a7867ae168d90e56c30893df6121000a94c0e8f Mon Sep 17 00:00:00 2001 From: Tom Wilkie Date: Wed, 23 Mar 2016 16:09:43 +0000 Subject: [PATCH] Fix spelling mistakes. --- docs/fastdp.md | 6 +++--- docs/weavedns-design.md | 4 ++-- ipam/allocator.go | 2 +- site/ip-addresses/configuring-weave.md | 8 ++++---- site/ipam/overview-init-ipam.md | 20 ++++++++++---------- site/troubleshooting.md | 2 +- site/weave-docker-api/set-up-proxy.md | 8 ++++---- site/weavedns-design.md | 4 ++-- 8 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/fastdp.md b/docs/fastdp.md index 51aa211ee7..df4d72a04b 100644 --- a/docs/fastdp.md +++ b/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 diff --git a/docs/weavedns-design.md b/docs/weavedns-design.md index 9059505c7f..dea9a6a0ee 100644 --- a/docs/weavedns-design.md +++ b/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. diff --git a/ipam/allocator.go b/ipam/allocator.go index bdc77f0888..325e74a990 100644 --- a/ipam/allocator.go +++ b/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() { diff --git a/site/ip-addresses/configuring-weave.md b/site/ip-addresses/configuring-weave.md index 8f3e2548d0..24f261504c 100644 --- a/site/ip-addresses/configuring-weave.md +++ b/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) \ No newline at end of file + * [IP Addresses, Routes and Networks](/site/ip-addresses/ip-addresses.md) diff --git a/site/ipam/overview-init-ipam.md b/site/ipam/overview-init-ipam.md index 35a3652c0b..4357c6fa65 100644 --- a/site/ipam/overview-init-ipam.md +++ b/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) - + ### 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) - - + + diff --git a/site/troubleshooting.md b/site/troubleshooting.md index 0a58f8919b..a84a1d6c36 100644 --- a/site/troubleshooting.md +++ b/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 diff --git a/site/weave-docker-api/set-up-proxy.md b/site/weave-docker-api/set-up-proxy.md index 26c42228cb..7db598ff03 100644 --- a/site/weave-docker-api/set-up-proxy.md +++ b/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 diff --git a/site/weavedns-design.md b/site/weavedns-design.md index 9059505c7f..dea9a6a0ee 100644 --- a/site/weavedns-design.md +++ b/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.