-
Notifications
You must be signed in to change notification settings - Fork 79
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
[WIP][controller] Add instance stoppable check based on CV states #1198
base: main
Are you sure you want to change the base?
Conversation
HelixCustomizedViewOfflinePushRepository customizedViewRepo = resources.getCustomizedViewRepository(); | ||
ReadWriteStoreRepository storeRepo = getHelixVeniceClusterResources(cluster).getStoreMetadataRepository(); | ||
|
||
for (String instanceId: instances) { |
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.
Can we unify the logic b/w this and node_removable
checks? That one already has the functionality of to_be_stopped_instances
through LOCKED_STORAGE_NODE_IDS
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.
May be not in this PR. node_removable
does not use CV and calling it in aggregate over a batch of instances require internal logic change.
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 can still abstract the main functionality into one method, and call it from two places. node_removable
can pass a single-element-list to this new function.
Also, this method can accept a RoutingDataRepository
, and stoppable-check
can pass CV repo while node_removable
can pass EV repo
68738b6
to
119d700
Compare
Add instance stoppable check based on CV states
Implement customized server stoppable check API in controller
The customized stoppable check takes a list of instances, along with a list of previously approved instances and decide which of these instances can be stopped.
For the instances that cannot be stopped, the controller returns an enum that denotes the reason for rejecting the request
{WILL_LOSE_DATA, MIN_ACTIVE_REPLICA_VIOLATION, ONGOING_MAINTENANCE, UNKNOWN_INSTANCE}
How was this PR tested?
Does this PR introduce any user-facing changes?