You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the new volumewatcher in #7794 and performance improvements to it that landed afterwards, there's no particular reason we should be threading claim releases through the GC eval rather than writing an empty CSIVolumeClaimRequest with the mode set to CSIVolumeClaimRelease, just as the GC evaluation would do.
This will reduce the amount of raft writes by 1 and reduce cross-server RPCs by 1 for each volume we release claims on.
These are the two places to replace new evals with de-duplicated CSIVolumeClaimBatchRequests:
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Following the new
volumewatcher
in #7794 and performance improvements to it that landed afterwards, there's no particular reason we should be threading claim releases through the GC eval rather than writing an emptyCSIVolumeClaimRequest
with the mode set toCSIVolumeClaimRelease
, just as the GC evaluation would do.This will reduce the amount of raft writes by 1 and reduce cross-server RPCs by 1 for each volume we release claims on.
These are the two places to replace new evals with de-duplicated
CSIVolumeClaimBatchRequest
s:job_endpoint.go#Job.Deregister
node_endpoint.go#Node.UpdateAlloc
The text was updated successfully, but these errors were encountered: