mirror of https://github.com/status-im/consul.git
website: omit excessive use of the word lastly
Simplify wording by removing various uses of the word lastly.
This commit is contained in:
parent
91c2939294
commit
880e21837c
|
@ -151,7 +151,7 @@ session that owns the lock.
|
||||||
|
|
||||||
The `Key` is simply the full path of the entry. `Flags` are an opaque
|
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
|
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
|
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
|
"?keys" query parameter along with a `GET` request. This will return
|
||||||
|
@ -211,9 +211,9 @@ then the update has not taken place.
|
||||||
|
|
||||||
### DELETE method
|
### DELETE method
|
||||||
|
|
||||||
Lastly, the `DELETE` method can be used to delete a single key or all
|
The `DELETE` method can be used to delete a single key or all keys sharing
|
||||||
keys sharing a prefix. There are a number of query parameters that can
|
a prefix. There are a number of query parameters that can be used with a
|
||||||
be used with a DELETE request:
|
DELETE request:
|
||||||
|
|
||||||
* ?recurse : This is used to delete all keys which have the specified prefix.
|
* ?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.
|
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
|
`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`
|
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
|
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
|
"unknown", "passing", "warning", or "critical". The "unknown" status is used
|
||||||
to indicate that the initial check has not been performed yet.
|
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
|
This endpoint does allow for filtering on events by name by providing
|
||||||
the `?name=` query parameter.
|
the `?name=` query parameter.
|
||||||
|
|
||||||
Lastly, to support [watches](/docs/agent/watches.html), this endpoint
|
To support [watches](/docs/agent/watches.html), this endpoint supports
|
||||||
supports blocking queries. However, the semantics of this endpoint
|
blocking queries. However, the semantics of this endpoint are slightly
|
||||||
are slightly different. Most blocking queries provide a monotonic index,
|
different. Most blocking queries provide a monotonic index, and block
|
||||||
and block until a newer index is available. This can be supported as
|
until a newer index is available. This can be supported as a consequence
|
||||||
a consequence of the total ordering of the [consensus protocol](/docs/internals/consensus.html).
|
of the total ordering of the [consensus protocol](/docs/internals/consensus.html).
|
||||||
With gossip, there is no ordering, and instead `X-Consul-Index` maps
|
With gossip, there is no ordering, and instead `X-Consul-Index` maps
|
||||||
to the newest event that matches the query.
|
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
|
the index as being opaque, clients should not be expecting a natural
|
||||||
ordering either.
|
ordering either.
|
||||||
|
|
||||||
Lastly, agents only buffer the most recent entries. The number
|
Agents only buffer the most recent entries. The number of entries should
|
||||||
of entries should not be depended upon, but currently defaults to
|
not be depended upon, but currently defaults to 256. This value could
|
||||||
256. This value could change in the future. The buffer should be large
|
change in the future. The buffer should be large enough for most clients
|
||||||
enough for most clients and watches.
|
and watches.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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
|
simpler to configure. This way the address and port of a service can
|
||||||
be discovered.
|
be discovered.
|
||||||
|
|
||||||
Lastly, a service can have an associated health check. This is a powerful
|
A service can have an associated health check. This is a powerful feature as
|
||||||
feature as it allows a web balancer to gracefully remove failing nodes, or
|
it allows a web balancer to gracefully remove failing nodes, or a database
|
||||||
a database to replace a failed slave, etc. The health check is strongly integrated
|
to replace a failed slave, etc. The health check is strongly integrated in
|
||||||
in the DNS interface as well. If a service is failing its health check or
|
the DNS interface as well. If a service is failing its health check or a
|
||||||
a node has any failing system-level check, the DNS interface will omit that
|
node has any failing system-level check, the DNS interface will omit that
|
||||||
node from any service query.
|
node from any service query.
|
||||||
|
|
||||||
There is more information about [checks here](/docs/agent/checks.html). The
|
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
|
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.
|
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
|
The type is either "client" meaning it cannot modify ACL rules, and is restricted
|
||||||
is restricted by the provided rules, or is "management" and is allowed to
|
by the provided rules, or is "management" and is allowed to perform all actions.
|
||||||
perform all actions.
|
|
||||||
|
|
||||||
The token ID is passed along with each RPC request to the servers. Agents
|
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,
|
[can be configured](/docs/agent/options.html) with `acl_token` to provide a default token,
|
||||||
|
|
Loading…
Reference in New Issue