From be2dfda78e2bcb100997bc5df874b1d451d8f09f Mon Sep 17 00:00:00 2001 From: Anita Buehrle Date: Tue, 8 Mar 2016 12:14:27 -0600 Subject: [PATCH] edits from awh --- site/ipam/overview-init-ipam.md | 2 +- site/ipam/stop-remove-peers-ipam.md | 4 ++-- site/using-weave/service-management.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/site/ipam/overview-init-ipam.md b/site/ipam/overview-init-ipam.md index c52ffca3..1850cec0 100644 --- a/site/ipam/overview-init-ipam.md +++ b/site/ipam/overview-init-ipam.md @@ -60,7 +60,7 @@ through three states: 'deferred', 'waiting' and 'achieved': themselves successfully * 'achieved' - consensus achieved; allocations proceed normally -Finally, you some peers can be launched as election observers using the +Finally, some peers can be launched as election observers using the `--observer` option: host4$ weave launch --observer $HOST3 diff --git a/site/ipam/stop-remove-peers-ipam.md b/site/ipam/stop-remove-peers-ipam.md index 1d9d0e2c..7c07645f 100644 --- a/site/ipam/stop-remove-peers-ipam.md +++ b/site/ipam/stop-remove-peers-ipam.md @@ -14,8 +14,8 @@ if Weave Net is run again on that node it will start from scratch. For failed peers, the `weave rmpeer` command can be used to permanently remove the ranges allocated to said peer. This allows -other peers to allocate IPs in the ranges previously owned by the removed peer -peer, and as such should be used with extreme caution - if the removed +other peers to allocate IPs in the ranges previously owned by the removed peer, +and as such should be used with extreme caution - if the removed peer had transferred some range of IP addresses to another peer but this is not known to the whole network, or if it later rejoins the Weave network, the same IP address may be allocated twice. diff --git a/site/using-weave/service-management.md b/site/using-weave/service-management.md index 172764ed..a58946f0 100644 --- a/site/using-weave/service-management.md +++ b/site/using-weave/service-management.md @@ -48,7 +48,7 @@ Weave hosts, regardless of where the actual application containers are located. Using the netcat service example described in [Deploying Applications](/site/using-weave/deploying-applications.md), and expanding upon it, you now decide to add a third containerized netcat service. This additional netcat service runs on `$HOST3`, and listens on port 2211, but it is not on the Weave network. -An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which is not accessible via `$HOST2`. Nonetheless, you still need to make a `$HOST3` service available to an application that is running in a container on `$HOST2`. +An additional caveat is that `$HOST3` can only be reached from `$HOST1`, which is not accessible via `$HOST2`. Nonetheless, you still need to make the `$HOST3` service available to an application that is running in a container on `$HOST2`. To satisfy this scenario, first expose the [application network to the host](/site/using-weave/host-network-integration.md) by running the following on `$HOST1`: