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

Add a wait for no intializing shards parameter to cluster health #25623

Closed
bleskes opened this issue Jul 10, 2017 · 5 comments
Closed

Add a wait for no intializing shards parameter to cluster health #25623

bleskes opened this issue Jul 10, 2017 · 5 comments
Assignees
Labels
:Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. good first issue low hanging fruit

Comments

@bleskes
Copy link
Contributor

bleskes commented Jul 10, 2017

Sometime it's handy to know everything has stabilized in the cluster when we run rest tests on it. A common problem is that we run the test on varying number of nodes. This means we sometime have assigned replicas other times there is a single node and thus the replicas will stay unassigned. This means we can't use wait for green or wait for yellow.

It will be handy to add a new options to the cluster health requests allowing to wait for all shard initialization to settle down (similar to the current option to wait for all relocations to stop). The new option may even supersede the relocation option (as it is a super set).

bleskes added a commit that referenced this issue Jul 10, 2017
Initializing replicas change the translog retention logic and confuses the test.

Switch to the solution suggested in #25623, if implemented
@Hogusong
Copy link

Hogusong commented Jul 25, 2017

I'd like to look into this as my first PR. is there a good place to start looking in the code to address this?

@bleskes
Copy link
Contributor Author

bleskes commented Jul 25, 2017

@Hogusong thanks for offering. You can look at the TransportClusterHealthAction code and how it handles the waitForNoRelocatingShards option.

@Hogusong
Copy link

@bleskes
So I'm looking at the TransportClusterHealthRequest and understand that I have to create a new member variable "waitForNoInitializingShards". However, I don't fully understand how to wait for all shard initializations to settle down. I see that waitForNoRelocatingShards is a boolean that's set on class creation but would like a little more information on how to structure "waitForNoInitializatingShards"

@jasontedor
Copy link
Member

However, I don't fully understand how to wait for all shard initializations to settle down.

@Hogusong You have to check the routing table in the cluster state and possibly wait for changes. I'm happy to give an even bigger hint, but I err on the side of less rather than more so as to not take away the joy of solving the problem.

@matarrese
Copy link
Contributor

Hello, I don't know if @Hogusong is still working on this issue, so I decided to bring it up and send you a pull request. It is not intended to be ready to be tested, as it is failing some tests. I am just asking if it's possible to have a review and understand if it goes in the right direction. If other people working on this, please feel free to close it.

@jasontedor jasontedor removed the help wanted adoptme label Sep 25, 2017
@ywelsch ywelsch added the help wanted adoptme label Nov 13, 2017
dnhatn added a commit to dnhatn/elasticsearch that referenced this issue Nov 22, 2017
This adds a new option to the cluster health request allowing to wait
until there is no initializing shards.

Closes elastic#25623
@dnhatn dnhatn self-assigned this Nov 22, 2017
@dnhatn dnhatn removed the help wanted adoptme label Nov 22, 2017
dnhatn added a commit that referenced this issue Nov 23, 2017
This adds a new option to the cluster health request allowing to wait
until there is no initializing shards.

Closes #25623
dnhatn added a commit that referenced this issue Nov 24, 2017
This adds a new option to the cluster health request allowing to wait
until there is no initializing shards.

Closes #25623
dnhatn added a commit to dnhatn/elasticsearch that referenced this issue Nov 27, 2017
dnhatn added a commit that referenced this issue Nov 27, 2017
@clintongormley clintongormley added :Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. and removed :Cluster labels Feb 13, 2018
dnhatn added a commit that referenced this issue Mar 31, 2018
dnhatn added a commit that referenced this issue Mar 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. good first issue low hanging fruit
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants