Skip to content

Commit

Permalink
Fix vale
Browse files Browse the repository at this point in the history
Signed-off-by: Thomas Farr <[email protected]>
  • Loading branch information
Xtansia committed Dec 26, 2024
1 parent 7dd1388 commit 715e0cd
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 15 deletions.
2 changes: 1 addition & 1 deletion spec/namespaces/cluster.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -808,7 +808,7 @@ components:
description: Unique identifier for the cluster.
$ref: '../schemas/_common.yaml#/components/schemas/Uuid'
indices:
description: Contains statistics about indices with shards assigned to selected nodes.
description: Contains statistics about indexes with shards assigned to selected nodes.
$ref: '../schemas/cluster.stats.yaml#/components/schemas/ClusterIndices'
nodes:
description: Contains statistics about nodes selected by the request's node filters.
Expand Down
28 changes: 14 additions & 14 deletions spec/schemas/cluster.reroute.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -11,47 +11,47 @@ components:
properties:
cancel:
description: |-
Cancel allocation of a shard (or recovery). Accepts index and shard for index
name and shard number, and node for the node to cancel the shard allocation
Cancel allocation of a shard (or recovery). Accepts `index` and `shard` for index
name and shard number, and `node` for the node to cancel the shard allocation
on. This can be used to force resynchronization of existing replicas from the
primary shard by cancelling them and allowing them to be reinitialized
through the standard recovery process. By default only replica shard
allocations can be cancelled. If it is necessary to cancel the allocation of
a primary shard then the allow_primary flag must also be included in the
a primary shard then the `allow_primary` flag must also be included in the
request.
$ref: '#/components/schemas/CommandCancelAction'
move:
description: |-
Move a started shard from one node to another node. Accepts index and shard
for index name and shard number, from_node for the node to move the shard
from, and to_node for the node to move the shard to.
Move a started shard from one node to another node. Accepts `index` and `shard`
for index name and shard number, `from_node` for the node to move the shard
from, and `to_node` for the node to move the shard to.
$ref: '#/components/schemas/CommandMoveAction'
allocate_replica:
description: |-
Allocate an unassigned replica shard to a node. Accepts index and shard for
index name and shard number, and node to allocate the shard to. Takes
Allocate an unassigned replica shard to a node. Accepts `index` and `shard` for
index name and shard number, and `node` to allocate the shard to. Takes
allocation deciders into account.
$ref: '#/components/schemas/CommandAllocateReplicaAction'
allocate_stale_primary:
description: |-
Allocate a primary shard to a node that holds a stale copy. Accepts the index
and shard for index name and shard number, and node to allocate the shard to.
Allocate a primary shard to a node that holds a stale copy. Accepts `index`
and `shard` for index name and shard number, and `node` to allocate the shard to.
Using this command may lead to data loss for the provided shard id. If a node
which has the good copy of the data rejoins the cluster later on, that data
will be deleted or overwritten with the data of the stale copy that was
forcefully allocated with this command. To ensure that these implications are
well-understood, this command requires the flag accept_data_loss to be
well-understood, this command requires the flag `accept_data_loss` to be
explicitly set to true.
$ref: '#/components/schemas/CommandAllocatePrimaryAction'
allocate_empty_primary:
description: |-
Allocate an empty primary shard to a node. Accepts the index and shard for
index name and shard number, and node to allocate the shard to. Using this
Allocate an empty primary shard to a node. Accepts `index` and `shard` for
index name and shard number, and `node` to allocate the shard to. Using this
command leads to a complete loss of all data that was indexed into this
shard, if it was previously started. If a node which has a copy of the data
rejoins the cluster later on, that data will be deleted. To ensure that these
implications are well-understood, this command requires the flag
accept_data_loss to be explicitly set to true.
`accept_data_loss` to be explicitly set to true.
$ref: '#/components/schemas/CommandAllocatePrimaryAction'
CommandCancelAction:
type: object
Expand Down

0 comments on commit 715e0cd

Please sign in to comment.