Ops edits (#2371)

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

@@ -4,29 +4,32 @@ menu_order: 30
 ---
 
 This scenario describes a production deployment of a fixed number of N
-nodes (N=1 in the simplest case). A uniform fixed cluster has the
-following characteristics:
+nodes (N=1 in the simplest case). 
+
+A uniform fixed cluster has the following characteristics:
 
 * Recovers automatically from reboots and partitions.
 * All peers have identical configuration.
 * There is a controlled process for adding or removing nodes, however
   the end user is responsible for ensuring that only one instance of
-  the process is in-flight at a time. Whilst it is possible to
+  the process is in-flight at a time. While it is possible to
   automate, the potentially-blocking `weave prime` operation and the
-  need for global serialisation make it non-trivial; it is however
+  need for global serialization make it non-trivial. It is however
   relatively straightforward for a human to provide the necessary
-  guarantees and exception handling manually, so this scenario is best
+  guarantees and exception handling manually, and so this scenario is best
   suited to deployments which change size infrequently as a planned
   maintenance event.
 
-### Bootstrap
+### Bootstrapping
 
 On each initial peer, at boot, via
 [systemd](/site/installing-weave/systemd.md):
 
     weave launch --no-restart $PEERS
 
-* `--no-restart` disables the Docker restart policy as this will be
+Where,
+
+* `--no-restart` disables the Docker restart policy, since this will be
   handled by systemd.
 * `$PEERS` is obtained from `/etc/sysconfig/weave` as described in the
   linked systemd documentation. For convenience, this may contain the
@@ -34,38 +37,42 @@ On each initial peer, at boot, via
   to compute separate lists of 'other' peers tailored to each peer -
   just supply the same complete list of peer addresses to every peer.
 
-Then on _any_ peer (note you can run this safely on more than one or
-even all peers, but it's only strictly necessary to run it on one of
-them):
+Then on _any_ peer run the following to force consensus:
 
     weave prime
 
-to force consensus - once this completes successfully, IP address
+>>**Note:** You can run this safely on more than one or
+even all peers, but it's only strictly necessary to run it on one of
+them. 
+
+Once this command completes successfully, IP address
 allocations can proceed under partition and it is safe to add new
-peers. If this command blocks it means that there is some issue (such
+peers. If this command waits without exiting, it means that there is an issue (such
 as a network partition or failed peers) that is preventing a quorum
 from being reached – you will need to [address
 that](/site/troubleshooting.md) before moving on.
 
-### Add a Peer
+### Adding a Peer
 
-On new peer, at boot, via
-[systemd](/site/installing-weave/systemd.md):
+On the new peer, at boot, via
+[systemd](/site/installing-weave/systemd.md) run:
 
     weave launch --no-restart $PEERS
 
-Where `$PEERS` is the new peer plus all other peers in the network,
+Where, 
+
+* `$PEERS` is the new peer plus all other peers in the network,
 initial and subsequently added, which have not been explicitly
 removed. It should include peers which are temporarily offline or
 stopped.
 
-For maximum robustness, you should then distribute an updated
+For maximum robustness, distribute an updated
 `/etc/sysconfig/weave` file including the new peer to all existing
 peers.
 
-### Remove a Peer
+### Removing a Peer
 
-On peer to be removed:
+On the peer to be removed:
 
     weave reset
 
@@ -77,4 +84,4 @@ On each remaining peer:
     weave forget <removed peer>
 
 This final step is not mandatory, but it will eliminate log noise and
-spurious network traffic by stopping reconnection attempts.
+spurious network traffic by stopping any reconnection attempts.