Enable updating EV configs on IS updates#3062
Enable updating EV configs on IS updates#3062LZD-PratyushBhatt wants to merge 1 commit intoapache:masterfrom
Conversation
d27a9e1 to
c7c268c
Compare
|
@junkaixue @xyuanlu Can you review this? Thanks! |
|
I am not sure about this "When a change is applied to the ideal_state of a resource, it’s expected that the EV reflect the changes. " |
|
Thanks for the review @xyuanlu |
|
I think this is too expensive to add IS listener just for updating configs (map fields) in EV. |
Issues
(#200 - Link your issue number here: You can write "Fixes #XXX". Please use the proper keyword so that the issue gets closed automatically. See https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue
Any of the following keywords can be used: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved)
Description
(Write a concise description including what, why, how)
Currently EV only gets updated only as part of these events CurrentStateChange, LiveInstanceChange, PeriodicRebalance, OnDemandRebalance and ControllerChange.
It doesnt get updated for IdealState changes. When a change is applied to the ideal_state of a resource, it’s expected that the EV reflect the changes. In cases of changes in configs like rebalancer algo, or min_active_replica, the change might not result in an assignment change, and Helix just forgets to update the EV to reflect these .
This change proposes updating the EV when IS changes. Keep EV an honest reflection of the state of the resource, when a resource-change event occurs. if it leads to change in assignment or not .
For updating EV, from IS we only take SimpleFields and putall the simple configs from IS to EV.
Tests
New test class
TestExternalViewComputeOnIdealStateChange(List the names of added unit/integration tests)
(If CI test fails due to known issue, please specify the issue and test PR locally. Then copy & paste the result of "mvn test" to here.)
Changes that Break Backward Compatibility (Optional)
(Consider including all behavior changes for public methods or API. Also include these changes in merge description so that other developers are aware of these changes. This allows them to make relevant code changes in feature branches accounting for the new method/API behavior.)
Documentation (Optional)
(Link the GitHub wiki you added)
Commits
Code Quality
(helix-style-intellij.xml if IntelliJ IDE is used)