-
Notifications
You must be signed in to change notification settings - Fork 1.1k
internal/factory/container: take dedicated CRI ContainerConfig.CDIDevices field into use. #6944
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
internal/factory/container: take dedicated CRI ContainerConfig.CDIDevices field into use. #6944
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #6944 +/- ##
==========================================
+ Coverage 49.16% 49.20% +0.03%
==========================================
Files 135 135
Lines 15484 15504 +20
==========================================
+ Hits 7612 7628 +16
- Misses 6970 6973 +3
- Partials 902 903 +1 |
e24ea17 to
1adb0b1
Compare
|
/retest-required |
TomSweeneyRedHat
left a comment
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.
Any man page changes needed?
There shouldn't be any. This change is about how a Kubernetes DRA driver requests CDI device injection into containers. It should be a non-user-visible change. Originally we lacked a dedicated CRI protocol field for this, so a CDI-specific annotation was used. Now, with a dedicated CRI protocol field in place, it became the primary/preferred way of communication. The original original annotation is still supported for backward compatibility. It will soon get marked as deprecated, at which point we'll start giving a warning about its usage. Eventually it will be removed altogether and we'll turn the warning into an error. |
|
/approve LGTM, test failures don't seem related |
| log.Infof(context.TODO(), | ||
| "Skipping duplicate annotated CDI device %s", name) | ||
| continue | ||
| } |
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.
Above is a valid warning. Can you add a test case covering this?
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.
@klihub would you like to handle this as a follow-up?
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.
Let's handle this in the follow-up PR
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.
Yeah, if it is OK for folks to just get this in and then handle that and anything else that might come up with with a follow-up PR, then I'd be for that, too.
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.
But let me rebase on latest main and check at the same time if I could add such a test with minimal effort.
|
A friendly reminder that this PR had no activity for 30 days. |
sohankunkerkar
left a comment
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.
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haircommander, klihub, sohankunkerkar The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
1adb0b1 to
eb7f5a5
Compare
3499c97 to
0872e24
Compare
Use the recently introduced CRI Config.CDIDevices field as the primary source of CDI device references to resolve and inject. Note that this commit does not remove CDI device injection using annotations. That will get deprecated and eventually removed in tandem with CDI itself. Signed-off-by: Krisztian Litkey <[email protected]>
0872e24 to
a3d229a
Compare
|
/retest |
| // of injecting CDI devices to give people time to update their DRA drivers. | ||
| // TODO(klihub): Change the log message to a warning once annotations are | ||
| // deprecated, and to an error once support is removed altogether. | ||
| _, annotated, err = cdi.ParseAnnotations(c.Config().GetAnnotations()) |
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.
should we mark them as deprecated for 1.28 and then remove them in 1.29?
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.
Yes, I think we should mark it deprecated. About removing support for it altogether, I think we should go in sync with what @bart0sh is doing on that front in containerd.
|
/retest |
|
/retest |
3 similar comments
|
/retest |
|
/retest |
|
/retest |
|
/override ci/prow/e2e-aws-ovn |
|
@haircommander: Overrode contexts on behalf of haircommander: ci/prow/e2e-aws-ovn DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What type of PR is this?
/kind other
What this PR does / why we need it:
Take the recently introduced CRI ContainerConfig.CDIDevices field into use as the primary source for CDI device resolution and injection..
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Note that this commit does not remove CDI device injection using annotations. That will get deprecated and eventually removed in tandem with CDI itself.
Does this PR introduce a user-facing change?