DRA API: implement ResourceClaim strategy for DRADeviceTaints#132927
DRA API: implement ResourceClaim strategy for DRADeviceTaints#132927k8s-ci-robot merged 2 commits intokubernetes:masterfrom
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions 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-sigs/prow repository. |
| // dropDisabledFields removes fields which are covered by a feature gate. | ||
| func dropDisabledFields(newClaim, oldClaim *resource.ResourceClaim) { | ||
| dropDisabledDRAPrioritizedListFields(newClaim, oldClaim) | ||
| dropDisabledDRADeviceTaintsFields(newClaim, oldClaim) // Intentionally after dropDisabledDRAPrioritizedListFields to avoid iterating over FirstAvailable slice which needs to be dropped. |
There was a problem hiding this comment.
Don't we need the same functionality in ResourceClaimTemplate?
There was a problem hiding this comment.
Yes. Will add it there, too. Good catch!
There was a problem hiding this comment.
For some reason, ResourceClaimTemplate update testing was less complete than the update testing of ResourceClaim. Fixed by copying the entire TestStrategyUpdate over and switching it to testing ResourceClaimTemplates.
I kept the existing test, to ensure that I am not removing coverage.
| } | ||
| }, | ||
| }, | ||
| "drop-fields-device-taints": { |
There was a problem hiding this comment.
Should we have tests here that covers interaction with the PrioritizedList feature?
| } | ||
| }, | ||
| }, | ||
| "drop-fields-device-taints-in-prioritized-list": { |
There was a problem hiding this comment.
Should we have some tests that don't include PrioritizedList?
There was a problem hiding this comment.
Yes. Now I am questioning my own sanity. I could have sworn that I had added them.
edeec84 to
fd7c1c2
Compare
|
/assign @mortent Please check again, it should be complete now. |
fd7c1c2 to
9fb7bbf
Compare
I just saw this, paging in context ... this is fixing clearing an alpha field which was added in 1.33 in #130447? I think it's too late for any non-release-blocking changes in 1.34, and if 1.33 already released without this, I don't think we'd consider it release-blocking for 1.34 either. |
|
/milestone v1.35 |
|
/test pull-kubernetes-node-e2e-containerd-2-0-dra-alpha-beta-features We had a test flake with some tests not cleaning up properly after themselves, should be fixed now ( |
|
Thanks for the update, @tallclair will take a pass and then we can get this in |
|
Hello @pohly @tallclair @liggitt @mortent |
…or DRADeviceTaints This wasn't possible at the time of implementing the Device Taints API, at least not completely, because it depended on prioritized list being merged first, to cover the "FirstAvailable" field introduced together with that feature. That the device taints PR got merged despite this gap was an oversight. The confusing TODO probably didn't help: the entire implementation was missing (or got lost due to a bad merge conflict resolution, not sure anymore) and it referenced the wrong other feature (partitionable devices doesn't affect ResourceClaim). For some reason, ResourceClaimTemplate update testing was less complete than the update testing of ResourceClaim. Fixed by copying the entire TestStrategyUpdate over and switching it to testing ResourceClaimTemplates.
c812bbd to
b556bbe
Compare
tallclair
left a comment
There was a problem hiding this comment.
lgtm, just a nit about the file path.
…mTemplate The spec is the same in both, so those fields are now handled by common code. For ResourceClaim spec updates, the "in use" check now only considers the spec. Theoretically some features could be in use in an old ResourceClaim status and not in use in the spec. This can only occur in a spec update, which is currently prevented because the entire spec is immutable. Even if it was allowed, preventing adding disabled fields to the spec is the right thing to do regardless of what may have ended up in the status earlier.
b556bbe to
da80b55
Compare
|
@pohly: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
|
/skip "fake.NewSimpleClientset is deprecated" - not sure whether I really should care. It's good enough here. |
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: 4515ae67cd2d34590c91b4f599dc8a1854a7c0bd |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, pohly 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 |
|
/cla |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Dropping the disabled "Tolerations" field in the ResourceClaim API was missing.
This wasn't possible at the time of implementing the Device Taints API, at least not completely, because it depended on prioritized list being merged first, to cover the "FirstAvailable" field introduced together with that feature.
That the device taints PR got merged despite this gap was an oversight. The confusing TODO probably didn't help: the entire implementation was missing (or got lost due to a bad merge conflict resolution, not sure anymore) and it referenced the wrong other feature (partitionable devices doesn't affect ResourceClaim).
Which issue(s) this PR is related to:
KEP: kubernetes/enhancements#5055
Special notes for your reviewer:
This allowed clients to set the field when it should have been dropped. It simply had no effect. Clients can keep updating such objects because of the "feature in use" check, as long as the spec remains immutable.
Does this PR introduce a user-facing change?