Integration testing has to this point relied on patching serving codecs for built-in APIs. The
test-only patching is removed and replaced by feature gated checks at runtime.
This had been left out unintentionally earlier. Because theoretically there
might now be existing objects with parameters that are larger than whatever
limit gets enforced now, the limit only gets checked when parameters get
created or modified.
This is similar to the validation of CEL expressions and for consistency, the
same 10 Ki limit as for those is chosen.
Because the limit is not enforced for stored parameters, it can be increased in
the future, with the caveat that users who need larger parameters then depend
on the newer Kubernetes release with a higher limit. Lowering the limit is
harder because creating deployments that worked in older Kubernetes will not
work anymore with newer Kubernetes.
The media type application/cbor describes exactly one encoded item. As a new (to Kubernetes) format
with no existing clients, streaming/watch responses will use the application/cbor-seq media
type. CBOR watch responses conform to the specification of CBOR Sequences and are encoded as the
concatenation of zero or more items with no additional framing.
The SELinuxWarningController does not necessarily need permissions to read
the objects, because it gets them through a shared informer instantiated by
KCM itself, but let's list the permissions for completeness.
This makes a configuration with --feature-gates=AllAlpha=true valid
again. Without this change, that flag enabled DRAAdminAccess without
DynamicResourceAllocation being enabled (default off!) and the kube-apiserver
refused to start.
While DRAAdminAccess isn't usable without DynamicResourceAllocation, it's also
not really wrong to allow it - it simply won't matter.
Supporting the alpha gRPC interface isn't enough anymore to be compatible
with kubelet 1.31: the "supported versions" must contain version numbers,
otherwise the older kubelet refuses to register the driver.
With this change, a DRA driver can decide to support both kubelet 1.31 and
kubelet 1.32 by registering *only* the alpha gRPC interface (NodeV1alpha4(true)
and NodeV1beta1(false) as options for Start).
The default is to provide both interfaces and using the registration mechanism
for 1.32, which makes DRA drivers compatible only with Kubernetes >= 1.32.
Listing supported gRPC services (e.g. drav1alpha3.Node, drav1beta1.DRAPlugin)
during registration enables the kubelet to determine in advance which methods
it can call.
Versioning by Kubernetes release makes less sense because it doesn't say
anything about which gRPC service is supported. New ones might get added and
obsolete ones removed. Some services might be optional.
In the past, this versioning support wasn't really used. At least one version
had to be provided and kubelet tried to use the plugin with the highest
version. This version comparison gets dropped. In the unlikely situation
that different plugins register under the same name, the most recent one is
used.
Because advertising gRPC services is a new convention, plugins only reporting
some version are treated as providing the old alpha gRPC service.
Using 1.0 was a workaround to grant Kubernetes 1.31 access to things introduce
in that same release. In Kubernetes 1.32 we don't need that workaround anymore
because everything is still available after a downgrade and thus usable.
This becomes relevant once DynamicResourceAllocation becomes beta with
"disabled" as default. Otherwise AllAlpha=true enables DRAAdminAccess which
depends on DynamicResourceAllocation, which is disabled.
This enables a future extension where capacity of a single device gets consumed
by different claims. The semantic without any additional fields is the same as
before: a capacity cannot be split up and is only an attribute of a device.
Because its semantically the same as before, two-way conversion to v1alpha3 is
possible.
This is meant to make it easier to remove the v1alpha3 because it won't be used
in clusters that started with DRA as beta in Kubernetes 1.32 when all clients
support v1beta1.
The tag is about the version/type combination, not just the type. The v1beta1
types will become deprecated automatically after three releases, starting in
1.32.
The v1alpha3 types get marked as replaced to ensure that the compatibility
version code doesn't force using v1alpha3 as storage
version (https://github.com/kubernetes/kubernetes/issues/128448).
The line coverage is now at 98.5% and several more corner cases are
covered. The remaining lines are hard or impossible to reach.
The actual validation is the same as before, with some small tweaks to the
generated errors.
When failures are not as expected, it is useful to show what the expected and
actual failures look like to a user. Perhaps even better would be to put the
expected texts into the test files instead of the error structs. That would
be easier to review and shorter.
