All version up to and including x.y.z-alpha.0 are treated as if we were
still the previous minor version x.(y-1). There are two reason for this:
- During code freeze around (at?) -rc.0, the master branch already
identfies itself as the next release with -alpha.0. Without this
special case, we would change the version skew testing from what
has been tested and been known to work to something else, which
can and at least once did break.
- Early in the next cycle the differences compared to the previous
release are small, so it's more interesting to go back further.
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>
When a Mutating Admission Policy (MAP) using ApplyConfiguration was applied to an existing object containing duplicate items in a list (e.g., duplicate environment variables), the operation would fail with a conversion error from Structured Merge Diff.
This change updates the `ApplyStructuredMergeDiff` function to use `typed.AllowDuplicates` when converting the `originalObject`. This allows MAP to process existing objects that may have technically invalid (duplicate) entries but are permitted by legacy validation.
New patches generated by the policy are still strictly validated and cannot introduce new duplicates.
Tests have been added to verify:
1. MAP can process an object with duplicate env vars.
2. MAP can modify an existing env var in an object with duplicates (which has the side effect of deduplicating the entry).
The allowRelaxedServiceNameValidation() function currently only checks
service names in spec.rules, but it should also check the service name
in spec.defaultBackend.
When an Ingress has a defaultBackend with a service name that is valid
per RFC 1123 but invalid per RFC 1035 (e.g., starting with a digit like
"1-default-service"), the function incorrectly returns false. This
prevents users from updating such Ingresses even though they were
validly created in the past.
This commit adds validation for spec.defaultBackend.service.name to
maintain backward compatibility for existing Ingresses.
