From 1a6e85320a86f303b3ad874c56109d2df224f28d Mon Sep 17 00:00:00 2001 From: Caleb Spare Date: Thu, 17 Apr 2014 14:45:53 -0700 Subject: [PATCH] Copy fixes: typos, misspellings, grammar, wording --- website/source/docs/guides/datacenters.html.markdown | 2 +- website/source/docs/guides/forwarding.html.markdown | 8 +++++--- website/source/docs/guides/servers.html.markdown | 6 ++---- website/source/docs/internals/architecture.html.markdown | 2 +- website/source/docs/internals/consensus.html.markdown | 2 +- website/source/intro/vs/nagios-sensu.html.markdown | 8 ++++---- website/source/intro/vs/skydns.html.markdown | 2 +- 7 files changed, 15 insertions(+), 15 deletions(-) diff --git a/website/source/docs/guides/datacenters.html.markdown b/website/source/docs/guides/datacenters.html.markdown index d29921d176..919f4c0ffd 100644 --- a/website/source/docs/guides/datacenters.html.markdown +++ b/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 diff --git a/website/source/docs/guides/forwarding.html.markdown b/website/source/docs/guides/forwarding.html.markdown index 2360229542..17f6b20b0e 100644 --- a/website/source/docs/guides/forwarding.html.markdown +++ b/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. diff --git a/website/source/docs/guides/servers.html.markdown b/website/source/docs/guides/servers.html.markdown index 2c8e065073..a1d207fbeb 100644 --- a/website/source/docs/guides/servers.html.markdown +++ b/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. diff --git a/website/source/docs/internals/architecture.html.markdown b/website/source/docs/internals/architecture.html.markdown index 1154433454..c7699f6154 100644 --- a/website/source/docs/internals/architecture.html.markdown +++ b/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. diff --git a/website/source/docs/internals/consensus.html.markdown b/website/source/docs/internals/consensus.html.markdown index ec52296593..98e52f778e 100644 --- a/website/source/docs/internals/consensus.html.markdown +++ b/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 diff --git a/website/source/intro/vs/nagios-sensu.html.markdown b/website/source/intro/vs/nagios-sensu.html.markdown index d3bad9284f..9f4dff32d4 100644 --- a/website/source/intro/vs/nagios-sensu.html.markdown +++ b/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 diff --git a/website/source/intro/vs/skydns.html.markdown b/website/source/intro/vs/skydns.html.markdown index aeb0ca9685..a81fc83807 100644 --- a/website/source/intro/vs/skydns.html.markdown +++ b/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.