Merge pull request #49 from cespare/copy-fixes-1

website: Copy fixes: typos, misspellings, grammar, wording

website/source/docs/guides/datacenters.html.markdown

@@ -6,7 +6,7 @@ sidebar_current: "docs-guides-datacenters"
 
 # Multi-Datacenter Deploys
 
-One of the key features of Consul is it's support for multiple datacenters.
+One of the key features of Consul is its support for multiple datacenters.
 The [architecture](/docs/internals/architecture.html) of Consul is designed to
 promote a low-coupling of datacenters, so that connectivity issues or
 failure of any datacenter does not impact the availability of Consul in other

website/source/docs/guides/forwarding.html.markdown

@@ -100,7 +100,8 @@ Then run the same query against your Bind instance and make sure you get a resul
 
 ### Troubleshooting
 
-If you don't get an answer from Bind but you do get an answer from Consul then your best bet is to turn on the query log to see what's going on:
+If you don't get an answer from Bind but you do get an answer from Consul then your
+best bet is to turn on the query log to see what's going on:
 
     [root@localhost ~]# rndc querylog
     [root@localhost ~]# tail -f /var/log/messages
@@ -110,5 +111,6 @@ In there if you see errors like this:
     error (no valid RRSIG) resolving
     error (no valid DS) resolving
 
-Then DNSSEC is not disabled properly.  If you see errors about network connections then verify that there are no firewall or routing problems between the servers running Bind and Consul
-
+Then DNSSEC is not disabled properly.  If you see errors about network connections
+then verify that there are no firewall or routing problems between the servers
+running Bind and Consul.

website/source/docs/guides/servers.html.markdown

@@ -64,7 +64,7 @@ the `last_log_index` shows the last log that is on disk. The same `info` command
 can be run on the new server to see how far behind it is. Eventually the server
 will be caught up, and the values should match.
 
-It is best to add servers one at a time, allowing them to catchup. This avoids
+It is best to add servers one at a time, allowing them to catch up. This avoids
 the possibility of data loss in case the existing servers fail while bringing
 the new servers up-to-date.
 
@@ -101,6 +101,4 @@ The leader should also emit various logs including:
     ...
 
 At this point the node has been gracefully removed from the cluster, and
-will shutdown.
-
-
+will shut down.

website/source/docs/internals/architecture.html.markdown

@@ -29,7 +29,7 @@ the node as either being a client or server, but there are other instances of th
 agents can run the DNS or HTTP interfaces, and are responsible for running checks and
 keeping services in sync.
 
-* Client - A client is an agent that forwards all RPC's to a server. The client is relatively
+* Client - A client is an agent that forwards all RPCs to a server. The client is relatively
 stateless. The only background activity a client performs is taking part of LAN gossip pool.
 This has a minimal resource overhead and consumes only a small amount of network bandwidth.
 

website/source/docs/internals/consensus.html.markdown

@@ -95,7 +95,7 @@ of 5 can tolerate 2 node failures. The recommended configuration is to either
 run 3 or 5 Consul servers per datacenter. This maximizes availability without
 greatly sacrificing performance. See below for a deployment table.
 
-In terms of performance, Raft is comprable to Paxos. Assuming stable leadership,
+In terms of performance, Raft is comparable to Paxos. Assuming stable leadership,
 committing a log entry requires a single round trip to half of the cluster.
 Thus performance is bound by disk I/O and network latency. Although Consul is
 not designed to be a high-throughput write system, it should handle on the order

website/source/intro/vs/nagios-sensu.html.markdown

@@ -25,13 +25,13 @@ and a weaker coupling between the servers and agents. However, the central broke
 has scaling limits, and acts as a single point of failure in the system.
 
 Consul provides the same health checking abilities as both Nagios and Sensu,
-is friendly to modern DevOps, and avoids the scaling issues inherint in the
-other systems. Consul runs all checks locally like Sensu avoiding placing
+is friendly to modern DevOps, and avoids the scaling issues inherent in the
+other systems. Consul runs all checks locally, like Sensu, avoiding placing
 a burden on central servers. The status of checks is maintained by the Consul
 servers, which are fault tolerant and have no single point of failure.
 Lastly, Consul can scale to vastly more checks because it relies on edge triggered
-updates. This means only when a check transitions from "passing" to "failing"
-or vice versa an update is triggered.
+updates. This means that an update is only triggered when a check transitions
+from "passing" to "failing" or vice versa.
 
 In a large fleet, the majority of checks are passing, and even the minority
 that are failing are persistent. By capturing changes only, Consul reduces

website/source/intro/vs/skydns.html.markdown

@@ -11,7 +11,7 @@ It uses multiple central servers that are strongly consistent and
 fault tolerant. Nodes register services using an HTTP API, and
 queries can be made over HTTP or DNS to perform discovery.
 
-Consul is very similar, but provides a super-set of features. Consul
+Consul is very similar, but provides a superset of features. Consul
 also relies on multiple central servers to provide strong consistency
 and fault tolerance. Nodes can use an HTTP API or use an agent to
 register services, and queries are made over HTTP or DNS.