Merge pull request #590 from ceh/website-docs
website: fix typo and omit excessive use of the word lastly
This commit is contained in:
commit
529679cdcd
|
@ -151,7 +151,7 @@ session that owns the lock.
|
|||
|
||||
The `Key` is simply the full path of the entry. `Flags` are an opaque
|
||||
unsigned integer that can be attached to each entry. The use of this is
|
||||
left totally to the user. Lastly, the `Value` is a base64 key value.
|
||||
left totally to the user. The `Value` is a base64 key value.
|
||||
|
||||
It is possible to also only list keys without their values by using the
|
||||
"?keys" query parameter along with a `GET` request. This will return
|
||||
|
@ -211,9 +211,9 @@ then the update has not taken place.
|
|||
|
||||
### DELETE method
|
||||
|
||||
Lastly, the `DELETE` method can be used to delete a single key or all
|
||||
keys sharing a prefix. There are a number of patameters that can
|
||||
be used with a DELETE request:
|
||||
The `DELETE` method can be used to delete a single key or all keys sharing
|
||||
a prefix. There are a number of query parameters that can be used with a
|
||||
DELETE request:
|
||||
|
||||
* ?recurse : This is used to delete all keys which have the specified prefix.
|
||||
Without this, only a key with an exact match will be deleted.
|
||||
|
@ -611,7 +611,7 @@ The `CheckID` can be omitted, and will default to the `Name`. Like before, the
|
|||
`CheckID` must be node-unique. The `Notes` is an opaque field that is meant to
|
||||
hold human readable text. If a `ServiceID` is provided that matches the `ID`
|
||||
of a service on that node, then the check is treated as a service level health
|
||||
check, instead of a node level health check. Lastly, the status must be one of
|
||||
check, instead of a node level health check. The `Status` must be one of
|
||||
"unknown", "passing", "warning", or "critical". The "unknown" status is used
|
||||
to indicate that the initial check has not been performed yet.
|
||||
|
||||
|
@ -1384,11 +1384,11 @@ may be different depending on their configuration.
|
|||
This endpoint does allow for filtering on events by name by providing
|
||||
the `?name=` query parameter.
|
||||
|
||||
Lastly, to support [watches](/docs/agent/watches.html), this endpoint
|
||||
supports blocking queries. However, the semantics of this endpoint
|
||||
are slightly different. Most blocking queries provide a monotonic index,
|
||||
and block until a newer index is available. This can be supported as
|
||||
a consequence of the total ordering of the [consensus protocol](/docs/internals/consensus.html).
|
||||
To support [watches](/docs/agent/watches.html), this endpoint supports
|
||||
blocking queries. However, the semantics of this endpoint are slightly
|
||||
different. Most blocking queries provide a monotonic index, and block
|
||||
until a newer index is available. This can be supported as a consequence
|
||||
of the total ordering of the [consensus protocol](/docs/internals/consensus.html).
|
||||
With gossip, there is no ordering, and instead `X-Consul-Index` maps
|
||||
to the newest event that matches the query.
|
||||
|
||||
|
@ -1397,10 +1397,10 @@ single agent, and has no meaning globally. Because Consul defines
|
|||
the index as being opaque, clients should not be expecting a natural
|
||||
ordering either.
|
||||
|
||||
Lastly, agents only buffer the most recent entries. The number
|
||||
of entries should not be depended upon, but currently defaults to
|
||||
256. This value could change in the future. The buffer should be large
|
||||
enough for most clients and watches.
|
||||
Agents only buffer the most recent entries. The number of entries should
|
||||
not be depended upon, but currently defaults to 256. This value could
|
||||
change in the future. The buffer should be large enough for most clients
|
||||
and watches.
|
||||
|
||||
It returns a JSON body like this:
|
||||
|
||||
|
|
|
@ -47,11 +47,11 @@ The `port` can be used as well to make a service oriented architecture
|
|||
simpler to configure. This way the address and port of a service can
|
||||
be discovered.
|
||||
|
||||
Lastly, a service can have an associated health check. This is a powerful
|
||||
feature as it allows a web balancer to gracefully remove failing nodes, or
|
||||
a database to replace a failed slave, etc. The health check is strongly integrated
|
||||
in the DNS interface as well. If a service is failing its health check or
|
||||
a node has any failing system-level check, the DNS interface will omit that
|
||||
A service can have an associated health check. This is a powerful feature as
|
||||
it allows a web balancer to gracefully remove failing nodes, or a database
|
||||
to replace a failed slave, etc. The health check is strongly integrated in
|
||||
the DNS interface as well. If a service is failing its health check or a
|
||||
node has any failing system-level check, the DNS interface will omit that
|
||||
node from any service query.
|
||||
|
||||
There is more information about [checks here](/docs/agent/checks.html). The
|
||||
|
|
|
@ -23,9 +23,8 @@ is modeled around "tokens".
|
|||
|
||||
Every token has an ID, name, type and rule set. The ID is a randomly generated
|
||||
UUID, making it unfeasible to guess. The name is opaque and human readable.
|
||||
Lastly the type is either "client" meaning it cannot modify ACL rules, and
|
||||
is restricted by the provided rules, or is "management" and is allowed to
|
||||
perform all actions.
|
||||
The type is either "client" meaning it cannot modify ACL rules, and is restricted
|
||||
by the provided rules, or is "management" and is allowed to perform all actions.
|
||||
|
||||
The token ID is passed along with each RPC request to the servers. Agents
|
||||
[can be configured](/docs/agent/options.html) with `acl_token` to provide a default token,
|
||||
|
|
Loading…
Reference in New Issue