diff --git a/website/source/docs/agent/encryption.html.markdown b/website/source/docs/agent/encryption.html.markdown index 281dfcf39..6de76cbe0 100644 --- a/website/source/docs/agent/encryption.html.markdown +++ b/website/source/docs/agent/encryption.html.markdown @@ -3,7 +3,7 @@ layout: "docs" page_title: "Encryption" sidebar_current: "docs-agent-encryption" description: |- - The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the encryption internals page. There are two seperate systems, one for gossip traffic and one for RPC. + The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the encryption internals page. There are two separate systems, one for gossip traffic and one for RPC. --- # Encryption @@ -11,7 +11,7 @@ description: |- The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the [encryption internals page](/docs/internals/security.html). There are two -seperate systems, one for gossip traffic and one for RPC. +separate systems, one for gossip traffic and one for RPC. ## Gossip Encryption @@ -74,7 +74,7 @@ key pair set using `cert_file` and `key_file`. If `verify_incoming` is set, then the servers verify the authenticity of all incoming connections. Servers will also disallow any non-TLS connections. If this is set, then all clients must have a valid key pair set using `cert_file` and `key_file`. To force clients to -use TLs, `verify_outgoing` must also be set. +use TLS, `verify_outgoing` must also be set. TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP and is secured using a symmetric key. See above for enabling gossip encryption. diff --git a/website/source/docs/agent/http.html.markdown b/website/source/docs/agent/http.html.markdown index 96055c7c6..0211ebae7 100644 --- a/website/source/docs/agent/http.html.markdown +++ b/website/source/docs/agent/http.html.markdown @@ -188,7 +188,7 @@ be used with a PUT request: * ?cas=\ : This flag is used to turn the `PUT` into a Check-And-Set operation. This is very useful as it allows clients to build more complex - syncronization primitives on top. If the index is 0, then Consul will only + synchronization primitives on top. If the index is 0, then Consul will only put the key if it does not already exist. If the index is non-zero, then the key is only set if the index matches the `ModifyIndex` of that key. @@ -607,7 +607,7 @@ If the API call succeeds a 200 status code is returned. ### /v1/catalog/deregister -The deregister endpoint is a low level mechanism for direclty removing +The deregister endpoint is a low level mechanism for directly removing entries in the catalog. It is usually recommended to use the agent local endpoints, as they are simpler and perform anti-entropy. diff --git a/website/source/docs/agent/options.html.markdown b/website/source/docs/agent/options.html.markdown index dbbda8d33..9790c8f9d 100644 --- a/website/source/docs/agent/options.html.markdown +++ b/website/source/docs/agent/options.html.markdown @@ -152,7 +152,7 @@ at a single JSON object with configuration within it. Configuration files are used for more than just setting up the agent, they are also used to provide check and service definitions. These are used to announce the availability of system servers to the rest of the cluster. -They are documented seperately under [check configuration](/docs/agent/checks.html) and +They are documented separately under [check configuration](/docs/agent/checks.html) and [service configuration](/docs/agent/services.html) respectively. The service and check definitions support being updated during a reload. @@ -188,7 +188,7 @@ definitions support being updated during a reload. * `acl_default_policy` - Either "allow" or "deny", defaults to "allow". The default policy controls the behavior of a token when there is no matching rule. In "allow" mode, ACLs are a blacklist: any operation not specifically - prohibited is allowed. In "deny" mode, ACLs are a whilelist: any operation not + prohibited is allowed. In "deny" mode, ACLs are a whitelist: any operation not specifically allowed is blocked. * `acl_down_policy` - Either "allow", "deny" or "extend-cache" which is the @@ -237,12 +237,12 @@ definitions support being updated during a reload. Must be provided along with the `key_file`. * `check_update_interval` - This interval controls how often check output from - checks in a steady state is syncronized with the server. By default, this is + checks in a steady state is synchronized with the server. By default, this is set to 5 minutes ("5m"). Many checks which are in a steady state produce slightly different output per run (timestamps, etc) which cause constant writes. - This configuration allows defering the sync of check output for a given interval to + This configuration allows deferring the sync of check output for a given interval to reduce write pressure. If a check ever changes state, the new state and associated - output is syncronized immediately. To disable this behavior, set the value to "0s". + output is synchronized immediately. To disable this behavior, set the value to "0s". * `client_addr` - Equivalent to the `-client` command-line flag. @@ -260,7 +260,7 @@ definitions support being updated during a reload. new version releases. * `dns_config` - This object allows a number of sub-keys to be set which can tune - how DNS queries are perfomed. See this guide on [DNS caching](/docs/guides/dns-cache.html). + how DNS queries are performed. See this guide on [DNS caching](/docs/guides/dns-cache.html). The following sub-keys are available: * `allow_stale` - Enables a stale query for DNS information. This allows any Consul @@ -395,7 +395,7 @@ port. * Serf LAN (Default 8301). This is used to handle gossip in the LAN. Required by all agents, TCP and UDP. -* Serf WAN( Default 8302). This is used by servers to gossip over the +* Serf WAN (Default 8302). This is used by servers to gossip over the WAN to other servers. TCP and UDP. * CLI RPC (Default 8400). This is used by all agents to handle RPC diff --git a/website/source/docs/agent/watches.html.markdown b/website/source/docs/agent/watches.html.markdown index b5dd857dc..5ab470721 100644 --- a/website/source/docs/agent/watches.html.markdown +++ b/website/source/docs/agent/watches.html.markdown @@ -32,7 +32,7 @@ in a JSON body when using agent configuration, or as CLI flags for the watch com ## Handlers -The watch specifiation specifies the view of data to be monitored. +The watch specification specifies the view of data to be monitored. Once that view is updated the specified handler is invoked. The handler can be any executable. diff --git a/website/source/docs/commands/event.html.markdown b/website/source/docs/commands/event.html.markdown index cfa55234c..15372d83e 100644 --- a/website/source/docs/commands/event.html.markdown +++ b/website/source/docs/commands/event.html.markdown @@ -16,7 +16,7 @@ to build scripting infrastructure to do automated deploys, restart services, or perform any other orchestration action. Events can be handled by [using a watch](/docs/agent/watches.html). -Under the hood, events are propogated using the [gossip protocol](/docs/internals/gossip.html). +Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip.html). While the details are not important for using events, an understanding of the semantics is useful. The gossip layer will make a best-effort to deliver the event, but there is **no guarantee** delivery. Unlike most Consul data, which is @@ -24,7 +24,7 @@ replicated using [consensus](/docs/internals/consensus.html), event data is purely peer-to-peer over gossip. This means it is not persisted and does not have a total ordering. In practice, this means you cannot rely on the order of message delivery. An advantage however is that events can still -be used even in the absense of server nodes or during an outage. +be used even in the absence of server nodes or during an outage. The underlying gossip also sets limits on the size of a user event message. It is hard to give an exact number, as it depends on various diff --git a/website/source/docs/commands/exec.html.markdown b/website/source/docs/commands/exec.html.markdown index 332f8f477..98c0af18e 100644 --- a/website/source/docs/commands/exec.html.markdown +++ b/website/source/docs/commands/exec.html.markdown @@ -16,7 +16,7 @@ the `web` service. Remote execution works by specifying a job which is stored in the KV store. Agent's are informed about the new job using the [event system](/docs/commands/event.html), -which propogates messages via the [gossip protocol](/docs/internals/gossip.html). +which propagates messages via the [gossip protocol](/docs/internals/gossip.html). As a result, delivery is best-effort, and there is **no guarantee** of execution. While events are purely gossip driven, remote execution relies on the KV store diff --git a/website/source/docs/internals/sessions.html.markdown b/website/source/docs/internals/sessions.html.markdown index fb8d3cba2..62f451e64 100644 --- a/website/source/docs/internals/sessions.html.markdown +++ b/website/source/docs/internals/sessions.html.markdown @@ -3,12 +3,12 @@ layout: "docs" page_title: "Sessions" sidebar_current: "docs-internals-sessions" description: |- - Consul provides a session mechansim which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems. + Consul provides a session mechanism which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems. --- # Sessions -Consul provides a session mechansim which can be used to build distributed locks. +Consul provides a session mechanism which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by [The Chubby Lock Service for Loosely-Coupled Distributed Systems](http://research.google.com/archive/chubby.html). @@ -31,7 +31,7 @@ Below is a diagram showing the relationship between these components: ![Consul Sessions](consul-sessions.png) -The contract that Consul provides is that under any of the folllowing +The contract that Consul provides is that under any of the following situations the session will be *invalidated*: * Node is deregistered @@ -79,7 +79,7 @@ mechanism by providing a zero delay value. Integration between the Key/Value store and sessions are the primary place where sessions are used. A session must be created prior to use, -and is then refered to by it's ID. +and is then referred to by it's ID. The Key/Value API is extended to support an `acquire` and `release` operation. The `acquire` operation acts like a Check-And-Set operation, except it diff --git a/website/source/intro/vs/chef-puppet.html.markdown b/website/source/intro/vs/chef-puppet.html.markdown index 7dcc4df77..8f3443f54 100644 --- a/website/source/intro/vs/chef-puppet.html.markdown +++ b/website/source/intro/vs/chef-puppet.html.markdown @@ -30,7 +30,7 @@ integrated health checking, Consul can route traffic away from unhealthy nodes, allowing systems and services to gracefully recover. Static configuration that may be provided by configuration management tools can be moved into the dynamic key/value store. This allows application configuration to be updated -without a slow convergence run. Lastly, because each datacenter runs indepedently, +without a slow convergence run. Lastly, because each datacenter runs independently, supporting multiple datacenters is no different than a single datacenter. That said, Consul is not a replacement for configuration management tools.