add CNI GC support #197
Merged
add CNI GC support #197
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openshift-ci
bot
added
release-note
Pull Request Test Coverage Report for Build 8797168456Details
💛 - Coveralls |
|
🤦 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>
saschagrunert
approved these changes
Apr 23, 2024
|
[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 |
openshift-ci
bot
added
the
approved
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 :-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
/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.