New validation logic follows the API ratcheting principle, will not be executed for already stored invalid if the corresponding fields or item in array is not modified. Please enter the commit message for your changes. Lines starting
test/integration/apiserver/apply covers the behavior of server-side-apply (SSA)
for official APIs. But there seem to be no integration tests which cover the
semantic of SSA like adding/removing/updating entries in a list map. This adds
such a test.
It needs an API which is under control of the test and uses
k8s.io/apimachinery/pkg/apis/testapigroup for that purpose, with some issues
fixed (OpenAPI code generation complained) and a new list map added.
Registering that API group in the apiserver needs a REST storage and
strategy. The API group only gets added in the test. However, the production
code has to know about it. In particular,
pkg/generated/openapi/zz_generated.openapi.go has to describe it.
Service storage implements transactions. It creates an IPAddress object first and then creates
the Service object, and if the Service object already exists the complete transaction is
reverted. There can be race conditions when the repair loop picks up the new IPAddress object
for reconciliation before the transaction is reverted. This leads to spurious
IPAddressWrongReference warnings, to suppress these warnings we delay the processing of the new
IPAddress object by 5 seconds. The service allocation creates the IPAddress object before creating
the Service object, we easily identify this scenario when the IPAddress object creation timestamp
is after the Service creation timestamp. We do this only when the IPAddress object is created
recently in order to avoid indefinitely requeue/delay in IPAddress cleanup if for some reason
the service transaction revert fails.
Signed-off-by: Daman Arora <aroradaman@gmail.com>
The private constructor for the repair loop now consumes clock.Clock interface allowing
predictable unit testing.
Signed-off-by: Daman Arora <aroradaman@gmail.com>
This change introduces the TokenRequestServiceAccountUIDValidation feature
gate and implements feature-gated service account UID validation for the
TokenRequest API. When enabled, the API validates that the service account
UID in token requests matches the actual service account UID, preventing
token requests for recreated service accounts with the same name but
different UIDs.
Signed-off-by: Anish Ramasekar <anish.ramasekar@gmail.com>
Introduce a test suite that ensures declarative test cases
are fully tested and that validation errors are compared
with handwritten validation to ensure consistency.
After declarative validation is enabled in the CertificateSigningRequest
strategy in this way, the generated declarative validation code
in will be run
when the strategy validates CertificateSigningRequest.
The v1alpha3 version is still needed for DeviceTaintRule, but the rest of the
types and most structs became obsolete in v1.32 when we introduced v1beta1 and
bumped the storage version to v1beta1.
Removing them now simplifies adding new features because new fields don't need
to be added to these obsolete types. This could have been done already in 1.33,
but wasn't to minimize disrupting on-going work.
