Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cluster Health API consistency with wait for shards parameters #20216

Closed
abeyad opened this issue Aug 29, 2016 · 0 comments
Closed

Cluster Health API consistency with wait for shards parameters #20216

abeyad opened this issue Aug 29, 2016 · 0 comments

Comments

@abeyad
Copy link

abeyad commented Aug 29, 2016

Right now, the cluster health API can take parameters including: wait_for_active_shards and wait_for_relocating_shards. The idea with these parameters is that we may want to wait for the cluster health check to return only after certain conditions are met - for example, a certain number of active shards are found in the cluster (across all indices) or there are only a certain number of relocating shards in the cluster. Both of these parameters take a numeric value (integer).

With the introduction of wait_for_active_shards in place of write consistency level in #19454, it makes sense to have a single consistent usage of wait_for_active_shards. In the case of the replication operations, wait_for_active_shards is a string that can be all, default (whatever the default value is for the intended operation), or a numeric value as a string (e.g. 1, 2, etc).

The proposal is to have the cluster health API also use this "string" version of wait_for_active_shards, consistent with usage in the replication/write operations, where a numeric value can be set as well as all and default. In the case of the cluster health API, specifying all means that we check the current active shard count across all indices against the total shard count (primary + replicas, active + inactive) for all indices in the cluster.

In addition, to keep things consistent, the proposal is also to have wait_for_relocating_shards no longer take a number. Instead, it would make sense to have that as a boolean parameter wait_for_no_relocating_shards, which would just indicate whether we will wait for all relocating shards to complete or not. This is likely the only usage of the current wait_for_relocating_shards, as in general you are only concerned about the case of there being no more active relocations - otherwise the exact number of them is likely not something one is concerned with when checking cluster health. Also, all of our test cases only use 0 for the wait_for_relocating_shards` value right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant