-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-29202 Balancer conditionals make balancer actions more likely to be approved #6821
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
Conversation
|
|
||
| if (isViolatingPre && isViolatingPost) { | ||
| if (isViolatingPre == isViolatingPost) { | ||
| return 0; |
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.
We also want to return 0 if we had zero violations both pre & post. Prior to this fix, we'd fall through to return -1 which erroneously considered a neutral move to be an improvement
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.
Since this was so impactful to behavior, maybe good to capture this method in a unit test?
|
|
||
| if (isViolatingPre && isViolatingPost) { | ||
| if (isViolatingPre == isViolatingPost) { | ||
| return 0; |
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.
Since this was so impactful to behavior, maybe good to capture this method in a unit test?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
e21aaaf to
6226730
Compare
| /** | ||
| * If your minCostNeedsBalance is set too low, then the balancer should still eventually stop making | ||
| * moves as further cost improvements become impossible, and balancer plan calculation becomes | ||
| * wasteful. This test ensures that the balancer will not get stuck in a loop of continuously moving | ||
| * regions. | ||
| */ | ||
| @Category({ MasterTests.class, MediumTests.class }) | ||
| public class TestUnattainableBalancerCostGoal { |
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.
This test fails on master atm (if balancer conditionals are enabled). It passes with this patch
| if (balancerRuns > 1000) { | ||
| if (balancerRuns > 10) { |
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.
I validated locally that this change is okay, will see if the tests also pass in CI. If it's taking more than 10 balancer runs for a test, then we should probably increase that tests max run time to make it more efficient
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
ndimiduk
left a comment
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.
Nice one!
| private CandidateGeneratorTestUtil() { | ||
| } | ||
|
|
||
| enum ExhaustionType { |
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.
👍
…o be approved (#6821) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…o be approved (#6821) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…o be approved (apache#6821) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…ions more likely to be approved (apache#6821) (will be in 2.7) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…ions more likely to be approved (apache#6821) (will be in 2.7) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…o be approved (apache#6821) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…o be approved (#6821) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…ions more likely to be approved (apache#6821) (will be in 2.7) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…ions more likely to be approved (apache#6821) (will be in 2.7) Co-authored-by: Ray Mattingly <rmattingly@hubspot.com> Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…o be approved (apache#6821) (apache#6837) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org> Co-authored-by: Ray Mattingly <rmattingly@hubspot.com>
Because we'll accept any moves that improve conditional violations, this bug can cause us to erroneously approve balancer actions.