When parsing a config file, all settings derived from command line flags are
discarded because only the config settings are used. That has been the
traditional behavior for non-logging flags.
But `--config ... -v=4` used to work until
71ef0dafa7 added logging to the configuration.
To restore the original behavior, kube-proxy now:
- parses flags
- reads the config file
- applies logging settings from the flags to the config loaded from file
- uses that merged config
The tests have been introduced in
ca7be7dc6d
and checked for `ecc` in `/proc/self/status` since its creation.
We got a new field `Seccomp_filters:` with the Linux commit
c818c03b66,
means that `ecc` would now match both and interfere with possible test
results depending on the host.
The field `Seccomp:` got introduced in
2f4b3bf6b2
and has never changed since then, means we can use it directly to make
the tests more strict.
Refers to https://github.com/kubernetes-sigs/cri-tools/pull/1236
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
PDB with an empty selector `{}` is selecting all the pods in a namespace.
But, during the `drain`, all the pods are getting evicted which is not expected.
This change should fix the issue and honor the pdb before evicting the pods.
Signed-off-by: Sai Ramesh Vanka <svanka@redhat.com>
Analyzing the CPU profile of
go test -timeout=0 -count=5 -cpuprofile profile.out -bench=BenchmarkPerfScheduling/.*Claim.* -benchtime=1ns -run=xxx ./test/integration/scheduler_perf
showed that a significant amount of time was spent iterating over allocated
claims to determine how many were allocated per node. That "naive" approach was
taken to avoid maintaining a redundant data structure, but now that performance
measurements show that this comes at a cost, it's not "premature optimization"
anymore to introduce such a second field.
The average scheduling throughput in
SchedulingWithResourceClaimTemplate/2000pods_100nodes increases from 16.4
pods/s to 19.2 pods/s.
klog prints an internal error when trying to log the podActions struct.
> I0505 14:12:12.827065 190662 kuberuntime_manager.go:1014] "computePodActions got for pod" podActions="<internal error: json: unsupported type: map[container.ContainerID]kuberuntime.containerToKillInfo>" pod="kube-system/coredns-8f5847b64-mzw46"
Implement the stringer interface on the struct to avoid the json error.
Change-Id: I22444524a78a0ecec9490b9240def371a4129434
EndpointSlices is the evolution of the Endpoint object and most of the
components are using it for implementing Services, this menas that
despite the Endpoint object is up to date, the EndpointSlices may
lag behind, so test must ensure that both objects are in sync to
avoid race conditions.
Change-Id: I5d9bc7774c68f321537379d1f20b2a1fe0b39e6e
In v1.27 StatefulSetStartOrdinal became beta, which makes it on by
default, but we forgot to turn these tests on along with it. This makes
these tests run always.
When binding has failed, `Done` gets called by
`handleBindingCycleError`. Calling it again is at best redundant and worse,
suffers from a data race:
- the `assumedPodInfo` is placed in the backoff queue
- an event causes the `Pod` pointer to get updated in it
- reading `assumedPodInfo.Pod.UID` races with that write
This race was found with`go test -race`.
Client-side extract calls depend on `managedFields`, which might not be
available. Therefore they should not be used in production code.
They are okay in test files (because the API has to be tested), in the
generated code (because the various type specific APIs still need to be
provided) and in unstructured.go (same reason).
