The ipallocator was blindly assuming that all errors are retryable, that
causes that the allocator tries to exhaust all the possibilities to
allocate an IP address.
If the error is not retryable this means the allocator will generate as
many API calls as existing available IPs are in the allocator, causing
CPU exhaustion since this requests are coming from inside the apiserver.
In addition to handle the error correctly, this patch also interpret the
error to return the right status code depending on the error type.
Co-authored-by: carlory <baofa.fan@daocloud.io>
* Reports node declared features in Node.Status.DeclaredFeatures.
* Add kubelet admission handler to check pod required features and match with node declared features on pod creation.
* Checks node declared features on pod updates and emits events if the node does not
satisfy the pod's feature requirements.
* Adds API validation for node object.
- Add feature gate to control mutable pod resources for suspended jobs
- Implement validatePodResourceUpdatesOnly function to allow only container resource updates
- Allow resource updates for suspended jobs regardless of whether they have started
- Add comprehensive unit and integration tests for all scenarios including started-then-suspended
- Ensure backward compatibility when feature gate is disabled
This enables users to update container resources on suspended jobs, including jobs that
have previously started and been suspended, while maintaining immutability for all other
pod template fields.
- 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.
