- Fix setting distinctAttribute=nil when DRAConsumableCapacity is disabled
- Add must have no error check when no error expected in strategy test
- Update test case that causes unexpected errors
Signed-off-by: Sunyanan Choochotkaew <sunyanan.choochotkaew1@ibm.com>
This raises the number of allowed taints per device to 16 by lowering
the number of allowed devices to 64 per ResourceSlice if (and only if!)
taints are used.
"effect: None" and DeviceTaintRule status with conditions get added
to support giving feedback to admins.
Instead of merely adding the new effect value, this also changes validation of
the enum so that unknown values are valid if they were already stored. This
will simplify adding new effects in the future because validation won't fail
for them after a downgrade. Consumers must treat them like this new None
effect, i.e. ignore them.
Add a unit test to to verify the uniqueness validation for . This ensures that duplicate request names within this field are correctly flagged as invalid.
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.
This commit introduces enum-based validation for the `AllocationConfigSource` field.
The following changes are included:
- The `AllocationConfigSource` type is now marked with `+k8s:enum`.
- The `Source` field in `DeviceAllocationConfiguration` is marked as required.
- Generated validation files are updated to enforce the enum constraint.
- A declarative validation test is added for the `AllocationConfigSource` field.
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.