This was added to Go 1.21, and makes the code simpler.
(Best reviewed ignoring changes in amount of whitespace).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
runc/libcontainer/cgroups.ParseCgroupFile is a universal function; for
cgroup v2 it returns path to unified in a map with "" as a key.
Let's use it here, dropping cgroups dependency entirely.
Amends commit e86d02b60c.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
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>
- add a new boolean field
IgnoreStoreReadErrorWithClusterBreakingPotential to meta/v1 DeleteOptions
- add validation for the new delete option
add validation for the new field in the delete options
ignoreStoreReadErrorWithClusterBreakingPotential
- prevent the pod eviction handler from issuing an unsafe pod delete
prevent the pod eviction handler from enabling the
'ignoreStoreReadErrorWithClusterBreakingPotential' delete option
New gate "InPlacePodVerticalScalingExclusiveCPUs" is off by default,
but can be enabled to unblock development of Static CPU management alongside
InPlacePodVerticalScaling.
Since the GA graduation of memory manager in https://github.com/kubernetes/kubernetes/pull/128517
we are sharing the initial container map across managers.
The intention of this sharing was not to actually share a data
structure, but
1. save the relatively expensive relisting from runtime
2. have all the managers share a consistent view - even though the
chance for misalignement tend to be tiny.
The unwanted side effect though is now all the managers race
to modify a data shared, not thread safe data structure.
The fix is to clone (deepcopy) the computed map when passing it
to each manager. This restores the old semantic of the code.
This issue brings the topic of possibly managers go out of sync
since each of them maintain a private view of the world.
This risk is real, yet this is how the code worked for
most of the lifetime, so the plan is to look at this and evaluate
possible improvements later on.
Signed-off-by: Francesco Romani <fromani@redhat.com>
Clients must be able to use CBOR without a guarantee that all apiservers support it. The apiserver
aggregation layer avoids changing in any way that would require an aggregated apiservers to be
updated. This end-to-end test verifies that a client's content negotiation behaviors continue to
work over time when communicating with a 1.17 sample-apiserver.
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.
