With the ClientsAllowCBOR client-go feature gate enabled, a 415 response to a CBOR-encoded REST
causes all subsequent requests from the client to fall back to a JSON request encoding. This
mechanism had only worked as intended when CBOR was explicitly configured in the
ClientContentConfig. When both ClientsAllowCBOR and ClientsPreferCBOR are enabled, an
unconfigured (empty) content type defaults to CBOR instead of JSON. Both ways of configuring a
client to use the CBOR request encoding are now subject to the same fallback mechanism.
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.
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.
For alpha, there is one apiserver feature gate and two client-go feature gates controlling
CBOR. They were initially wired to separate test-only feature gate instances in order to prevent
them from being configurable at runtime via command-line flags or environment variables (for
client-go feature gates outside of Kubernetes components). All of the integration tests required by
the KEP as alpha criteria have been implemented. This adds the feature gates to the usual feature
gate instances and removes the temporary code to support separate test-only feature gate instances.
If a client is configured to encode request bodies to CBOR, but the server does not support CBOR,
the server will respond with HTTP 415 (Unsupported Media Type). By feeding this response back to the
RESTClient, subsequent requests can fall back to JSON, which is assumed to be acceptable.
builds on #62868
1. When the incoming patch specified a resourceVersion that failed as a precondition,
the patch handler would retry uselessly 5 times. This PR collapses onto GuaranteedUpdate,
which immediately stops retrying in that case.
2. When the incoming patch did not specify a resourceVersion, and persisting to etcd
contended with other etcd updates, the retry would try to detect patch conflicts with
deltas from the first 'current object' retrieved from etcd and fail with a conflict error
in that case. Given that the user did not provide any information about the starting version
they expected their patch to apply to, this does not make sense, and results in arbitrary
conflict errors, depending on when the patch was submitted relative to other changes made
to the resource. This PR changes the patch application to be performed on the object retrieved
from etcd identically on every attempt.
fixes#58017
SMP is no longer computed for CRD objects
fixes#42644
No special state is retained on the first attempt, so the patch handler correctly handles
the cached storage optimistically trying with a cached object first
