-
Notifications
You must be signed in to change notification settings - Fork 54
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
add CNI GC support #197
add CNI GC support #197
Conversation
Pull Request Test Coverage Report for Build 8797168456Details
💛 - Coveralls |
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.
Code LGTM but the linter is not happy with that change.
🤦 fixed, thanks! |
We have two locks: - per-pod lock to prevent parallel operations - plugin-level lock to prevent races on network configurations We don't actually use the latter correctly; we could find ourselves in a funny state where we read default network name A, but then it changes before we issue the CNI ADD. So, just hold the plugin read-lock during all pod operations. This prevents any sort of racing between pod operations and config reloading. An extra quirk is that we opportunistically re-sync config on failure. This is to fix a podman test flake. It needs a bit of awkward re-locking but it should rarely happen. It's also not a deadlock risk thanks to careful ordering. Signed-off-by: Casey Callendrello <c1@caseyc.net>
This introduces CNI GC support, a mode in which the runtime provides a list of expected attachments, and then network plugins can clean up stale resources such as IPAM attachments. Because CNI GC is not allowed to take place in parallel with any other pod operations, a new top-level lock was added. I did not use the plugin lock, as GC should not block non-pod calls such as STATUS. Signed-off-by: Casey Callendrello <c1@caseyc.net>
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.
Thanks! Do we need a new release after this change?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: saschagrunert, squeed The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Eventually, yes. I’d like to prototype GC support in crio first; let me play at that for a little while. is there a cri-o release imminent? |
@squeed we're planning to cut v1.30.0 in the next week(s), yes. We still need go 1.22 in CI, so we may delay here a bit. |
@saschagrunert I haven't gotten time to check this, but that's OK. Cut a release at your leisure :-) |
/kind feature
This adds CNI GC support. GC is a CNI verb that allows runtimes (i.e. cri-o) to specify a list of known-good attachments, allowing network plugins to clean up stale resources. This permits cleanup of, for example, leaked IPAM allocations.
This does require rethinking the locking approach slightly, as GC cannot be executed in paralle with other pod operations.