zpinto opened a new pull request, #2740:
URL: https://github.com/apache/helix/pull/2740

   ### Issues
   
   - [x] Instance Evacuation is causing shuffling after dropping an evacuated 
node. This is a result of new baseline being computed.
   - [x] Remove unnecessary logic to handle SWAP_IN node in preferenceList, 
this was from old approach.
   
   ### Description
   
   We are now controlling the filtering of certain "Assignable" instances 
through the BaseControllerDataProvider. This will help centralize the logic and 
decouple it with the rebalancers. This PR migrates EVACUATE to this approach. 
Putting this logic here, allows methods like getAssignableInstanceConfigMap to 
respect the "Assignable" states. When the return value for this changes, a new 
baseline is computed. If it differs, which it will for evacuate, it will cause 
shuffling.
   
   When the baseline is calculated, whether it is enabled, live, or set to 
EVACUATE is not respected. The assignment assumes the "happy path" where all of 
these instances are assignable or will be assignable. When and EVACUATE node is 
dropped, it will force a differing baseline to be calculated. This will cause 
shuffling after the evacuation is complete.
   
   To fix this, setting and InstanceOperation to EVACUATE will ensure that it 
does not get returned in getAssignable*. This forces the baseline to be 
recomputed without considering the EVACUATE instance. When the instance is 
dropped, the arguments to baseline computation are the same as the previous 
computation and there is no change.
   
   To maintain N -> N + 1 -> N behavior, we change the 
computeBestPossiblePartition state to pass all liveInstances so that the 
replicas on the EVACUATE instance can still be part of the stateMap until the 
new replica is created.
   
   ### Tests
   
   - [x] Update testEvacuate to ensure no additional shuffling after the 
evacuated instance is dropped.
   
   
   ### Changes that Break Backward Compatibility (Optional)
   
   - Removed some public methods; however, they were relatively new and would 
likely cause more confusion if they were left. If objections, I can deprecate 
them instead. Also, I don't think any were part of an open-source release.
   
   ### Documentation (Optional)
   
   NA
   
   ### Commits
   
   - My commits all reference appropriate Apache Helix GitHub issues in their 
subject lines. In addition, my commits follow the guidelines from "[How to 
write a good git commit message](http://chris.beams.io/posts/git-commit/)":
     1. Subject is separated from body by a blank line
     1. Subject is limited to 50 characters (not including Jira issue reference)
     1. Subject does not end with a period
     1. Subject uses the imperative mood ("add", not "adding")
     1. Body wraps at 72 characters
     1. Body explains "what" and "why", not "how"
   
   ### Code Quality
   
   - My diff has been formatted using helix-style.xml 
   (helix-style-intellij.xml if IntelliJ IDE is used)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to