status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #4127 from pierresouchay/documentation_discovery_max_stale 

Error in documentation: `discovery_max_stale` is not in `dns_config`
This commit is contained in:
Preetha 2018-05-16 08:52:21 -05:00 committed by GitHub
parent 37cd264a8b c5dfe7b97d
commit fbef55c1cc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
website/source/docs/agent/options.html.md
View File

@ -695,6 +695,16 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
to the Consul raft log in environments where health checks have volatile output like
timestamps, process ids, ...
* <a name="discovery_max_stale"></a><a href="#discovery_max_stale">`discovery_max_stale`</a> - Enables
stale requests for all service discovery HTTP endpoints. This is equivalent to the
[`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service
discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server
can handle the service discovery request. If a Consul server is behind the leader by more than `discovery_max_stale`,
the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new
`X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale`
was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level,
and defaults to zero which matches default consistency behavior in earlier Consul versions.
* <a name="dns_config"></a><a href="#dns_config">`dns_config`</a> This object allows a number
of sub-keys to be set which can tune how DNS queries are serviced. See this guide on
[DNS caching](/docs/guides/dns-cache.html) for more detail.
@ -717,17 +727,6 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
leader, so this lets Consul continue serving requests in long outage scenarios where no leader can
be elected.
* <a name="discovery_max_stale"></a><a href="#discovery_max_stale">`discovery_max_stale`</a> - Enables
stale requests for all service discovery HTTP endpoints. This is equivalent to the
[`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service
discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server
can handle the service discovery request. If a Consul server is behind the leader by more than `discovery_max_stale`,
the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new
`X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale`
was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level,
and defaults to zero which matches default consistency behavior in earlier Consul versions.
* <a name="node_ttl"></a><a href="#node_ttl">`node_ttl`</a> - By default, this is "0s", so all
node lookups are served with a 0 TTL value. DNS caching for node lookups can be enabled by
setting this value. This should be specified with the "s" suffix for second or "m" for minute.
@ -768,7 +767,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
When answering a question, Consul will use the complete list of
matching hosts, shuffle the list randomly, and then limit the number of
answers to `a_record_limit` (default: no limit). This limit does not apply to SRV records.
In environments where [RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9
is implemented and enforced (i.e. DNS answers are always sorted and
therefore never random), clients may need to set this value to `1` to