luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Fix some typos in website docs

This commit is contained in:
Danny Berger 2014-11-04 21:01:45 -07:00
parent f5acbace17
commit 4347b9394d
8 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
website/source/docs/agent/encryption.html.markdown
View File

@ -3,7 +3,7 @@ layout: "docs"
page_title: "Encryption" page_title: "Encryption"
sidebar_current: "docs-agent-encryption" sidebar_current: "docs-agent-encryption"
description: |- 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 # Encryption
@ -11,7 +11,7 @@ description: |-
The Consul agent supports encrypting all of its network traffic. The exact The Consul agent supports encrypting all of its network traffic. The exact
method of this encryption is described on the method of this encryption is described on the
[encryption internals page](/docs/internals/security.html). There are two [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 ## 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 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 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 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 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. and is secured using a symmetric key. See above for enabling gossip encryption.

4
website/source/docs/agent/http.html.markdown
View File

@ -188,7 +188,7 @@ be used with a PUT request:
* ?cas=\<index\> : This flag is used to turn the `PUT` into a Check-And-Set * ?cas=\<index\> : 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 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 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. 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.
### <a name="catalog_deregister"></a> /v1/catalog/deregister ### <a name="catalog_deregister"></a> /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 entries in the catalog. It is usually recommended to use the agent local
endpoints, as they are simpler and perform anti-entropy. endpoints, as they are simpler and perform anti-entropy.

14
website/source/docs/agent/options.html.markdown
View File

@ -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, 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 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. 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 [service configuration](/docs/agent/services.html) respectively. The service and check
definitions support being updated during a reload. 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 * `acl_default_policy` - Either "allow" or "deny", defaults to "allow". The
default policy controls the behavior of a token when there is no matching 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 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. specifically allowed is blocked.
* `acl_down_policy` - Either "allow", "deny" or "extend-cache" which is the * `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`. Must be provided along with the `key_file`.
* `check_update_interval` - This interval controls how often check output from * `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 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. 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 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. * `client_addr` - Equivalent to the `-client` command-line flag.
@ -260,7 +260,7 @@ definitions support being updated during a reload.
new version releases. new version releases.
* `dns_config` - This object allows a number of sub-keys to be set which can tune * `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: The following sub-keys are available:
* `allow_stale` - Enables a stale query for DNS information. This allows any Consul * `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. * Serf LAN (Default 8301). This is used to handle gossip in the LAN.
Required by all agents, TCP and UDP. 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. WAN to other servers. TCP and UDP.
* CLI RPC (Default 8400). This is used by all agents to handle RPC * CLI RPC (Default 8400). This is used by all agents to handle RPC

2
website/source/docs/agent/watches.html.markdown
View File

@ -32,7 +32,7 @@ in a JSON body when using agent configuration, or as CLI flags for the watch com
## Handlers ## 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 Once that view is updated the specified handler is invoked. The handler
can be any executable. can be any executable.

4
website/source/docs/commands/event.html.markdown
View File

@ -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 or perform any other orchestration action. Events can be handled by
[using a watch](/docs/agent/watches.html). [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 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 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 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 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 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 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 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 message. It is hard to give an exact number, as it depends on various

2
website/source/docs/commands/exec.html.markdown
View File

@ -16,7 +16,7 @@ the `web` service.
Remote execution works by specifying a job which is stored in the KV store. 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), 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. 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 While events are purely gossip driven, remote execution relies on the KV store

8
website/source/docs/internals/sessions.html.markdown
View File

@ -3,12 +3,12 @@ layout: "docs"
page_title: "Sessions" page_title: "Sessions"
sidebar_current: "docs-internals-sessions" sidebar_current: "docs-internals-sessions"
description: |- 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 # 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. 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 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). 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) ![Consul Sessions](consul-sessions.png)
</div> </div>
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*: situations the session will be *invalidated*:
* Node is deregistered * 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 Integration between the Key/Value store and sessions are the primary
place where sessions are used. A session must be created prior to use, 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 Key/Value API is extended to support an `acquire` and `release` operation.
The `acquire` operation acts like a Check-And-Set operation, except it The `acquire` operation acts like a Check-And-Set operation, except it

2
website/source/intro/vs/chef-puppet.html.markdown
View File

@ -30,7 +30,7 @@ integrated health checking, Consul can route traffic away from unhealthy
nodes, allowing systems and services to gracefully recover. Static configuration nodes, allowing systems and services to gracefully recover. Static configuration
that may be provided by configuration management tools can be moved into the that may be provided by configuration management tools can be moved into the
dynamic key/value store. This allows application configuration to be updated 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. supporting multiple datacenters is no different than a single datacenter.
That said, Consul is not a replacement for configuration management tools. That said, Consul is not a replacement for configuration management tools.