-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Improve awareness allocation explanation #69371
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
Improve awareness allocation explanation #69371
Conversation
Users sometimes struggle with unassigned shards due to the awareness decider, especially if the decider is using more zones than expected (e.g. a typo in an attribute value, or a stale forced-awareness config). It is hard to see why there are more zones than expected, or even really to tell from the message that this is the problem. This commit adds detail about the names of the zones that the allocation decider is using, so that users can see for themselves whether that is the source of the problem, and rewords it slightly to make it easier to understand.
Pinging @elastic/es-distributed (Team:Distributed) |
testExplanation(Settings.builder() | ||
.put(AwarenessAllocationDecider.CLUSTER_ROUTING_ALLOCATION_AWARENESS_ATTRIBUTE_SETTING.getKey(), "zone"), | ||
n -> n.add(newNode("X-0", emptyMap())), | ||
"there are [5] copies of this shard and [3] values for attribute [zone] ([<missing>, a, b] from nodes in the cluster and " + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On reflection I think this is a bug, we should be ignoring nulls completely, and although it didn't really matter in the past it does matter now. I opened #69374.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Users sometimes struggle with unassigned shards due to the awareness decider, especially if the decider is using more zones than expected (e.g. a typo in an attribute value, or a stale forced-awareness config). It is hard to see why there are more zones than expected, or even really to tell from the message that this is the problem. This commit adds detail about the names of the zones that the allocation decider is using, so that users can see for themselves whether that is the source of the problem, and rewords it slightly to make it easier to understand.
Users sometimes struggle with unassigned shards due to the awareness
decider, especially if the decider is using more zones than expected
(e.g. a typo in an attribute value, or a stale forced-awareness config).
It is hard to see why there are more zones than expected, or even really
to tell from the message that this is the problem.
This commit adds detail about the names of the zones that the allocation
decider is using, so that users can see for themselves whether that is
the source of the problem, and rewords it slightly to make it easier to
understand.