The validation ratcheting logic failed to distinguish between a field that was explicitly nil and a field that was absent in the old object (uncorrelated). safe.Field() returns nil in both scenarios.
This caused validation to be incorrectly skipped for oldObj that cannot be found during an update, as the logic treated the (nil, nil) old/new value pair as unchanged.
This commit introduces an oldValueCorrelated boolean flag to the generated validation functions. This flag is set to false when the parent of the old object is nil, signaling that a corresponding old value could not be found. The ratcheting check is now conditioned on this flag, ensuring that validation proceeds correctly.
Refactors the ValidationTester in testscheme to make update validation implicit. Calling .OldValue() now automatically triggers update validation, removing the need to pass an explicit operation type and simplifying the test-writing API.
This is applied to new tests that demonstrate a validation ratcheting bug where validation is incorrectly skipped when comparing a nil old value with a new value. The tests cover list items and struct fields to ensure the fix will be verified.
Support for DeviceTaintRules depends on a significant amount of
additional code:
- ResourceSlice tracker is a NOP without it.
- Additional informers and corresponding permissions in scheduler and controller.
- Controller code for handling status.
Not all users necessarily need DeviceTaintRules, so adding a second feature
gate for that code makes it possible to limit the blast radius of bugs in that
code without having to turn off device taints and tolerations entirely.
To update the right statuses, the controller must collect more information
about why a pod is being evicted. Updating the DeviceTaintRule statuses then is
handled by the same work queue as evicting pods.
Both operations already share the same client instance and thus QPS+server-side
throttling, so they might as well share the same work queue. Deleting pods is
not necessarily more important than informing users or vice-versa, so there is
no strong argument for having different queues.
While at it, switching the unit tests to usage of the same mock work queue as
in staging/src/k8s.io/dynamic-resource-allocation/internal/workqueue. Because
there is no time to add it properly to a staging repo, the implementation gets
copied.
Add a new `bindingTimeout` field to DynamicResources plugin args and wire it
into PreBind.
Changes:
- API: add `bindingTimeout` to DynamicResourcesArgs (staging + internal types).
- Defaults: default to 600 seconds when BOTH DRADeviceBindingConditions and
DRAResourceClaimDeviceStatus are enabled.
- Validation: require >= 1s; forbid when either feature gate is disabled.
- Plugin: plumbs args into `pl.bindingTimeout` and uses it in
`wait.PollUntilContextTimeout` for binding-condition wait logic.
- Plugin: remove legacy `BindingTimeoutDefaultSeconds`.
Tests:
- Add/adjust unit tests for validation and PreBind timeout path.
- Ensure <1s and negative values are rejected; forbids when gates disabled.
