KEP-4603: Maintain current 10 minute recovery threshold for container backoff regardless of changes to the maximum duration
Kubernetes-commit: ab30adcbae57fc498cb876979e232b422468af9a
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.
Kubernetes-commit: a77f4c7ba2e761461daaf115a38903fc91916dd6
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.
Kubernetes-commit: 439d2f7b4028638b3d8d9261bb046c3ba8d9bfcb
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.
Kubernetes-commit: 504f14998e920ca8837b3310094b3da11c62a070
This commit introduces:
1. Cleanups in port-forwarding error handling code, which ensures that
we only compare lowercased text always.
2. E2E verifying that when a pod is removed a port-forward is stopped.
Signed-off-by: Maciej Szulik <soltysh@gmail.com>
Kubernetes-commit: 0b1617ccefbc6ea61c0e7c2b0b4052703f11c51c
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.
Kubernetes-commit: 81fd64256c9cfca47385997e06a694bf98bfb799
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.
Kubernetes-commit: 072dfcb416fd4e1ddab0a89ac4faf519e268bc96
chore(leader-election): modify leader-election comment to OnStoppedLeading callback is always called when the LeaderElector exits, even if it did not start leading.
Kubernetes-commit: 1a7326902fa07b85e07de458dd2d4d4d99057d87
Using the "normal" logic for a feature gated field simplifies the
implementation of the feature gate.
There is one (entirely theoretic!) problem with updating from 1.31: if a claim
was allocated in 1.31 with admin access, the status field was not set because
it didn't exist yet. If a driver now follows the current definition of "unset =
off", then it will not grant admin access even though it should. This is
theoretic because drivers are starting to support admin access with 1.32, so
there shouldn't be any claim where this problem could occur.
Kubernetes-commit: 4419568259590c35f1dab69aabec3d740944a51d
