The node-kubelet-flaky e2e job that runs the the
`Node Performance Testing [Serial] [Slow] [Flaky]` e2e tests have been
flaking because of inconsistencies on the cpu manager checkpoint file.
This seems to be caused because the checkpoint file is deleted (which is
what needs to happen in order to change the CPU manager policy which is
used for these e2e tests) right after the e2e tests asserts that a pod
does not exist anymore.
However, after a pod is deleted, the CPU manager may still be cleaning
up the resources used by the pod which may result in the checkpoint file
being created.
Whenever this happened, the kubelet would panic if we then try to
subsequently change the CPU manager policy to "static" from "none" or
vice versa (this is done 4 times in these tests).
Signed-off-by: alejandrox1 <alarcj137@gmail.com>
We were detecting the IP family that kube-proxy should use
based on the bind address, however, this is not valid when
using an unspecified address, because on those cases
kube-proxy adopts the IP family of the address reported
in the Node API object.
The IP family will be determined by the nodeIP used by the proxier
The order of precedence is:
1. config.bindAddress if bindAddress is not 0.0.0.0 or ::
2. the primary IP from the Node object, if set
3. if no IP is found it defaults to 127.0.0.1 and IPv4
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
Hello gophers,
Version v0.3.3 of golang.org/x/text fixes a vulnerability in the golang.org/x/text/encoding/unicode package which could lead to the UTF-16 decoder entering an infinite loop, causing the program to crash or run out of memory.
An attacker could provide a single byte to a UTF16 decoder instantiated with UseBOM or ExpectBOM to trigger an infinite loop if the String function on the Decoder is called, or the Decoder is passed to golang.org/x/text/transform.String.
transform.String has also been hardened not to enter an infinite loop if a Transformer keeps returning ErrShortSrc even if atEOF is true.
This issue was first filed as Issue 39491 by GitHub user abacabadabacaba and reported to the security team by Anton Gyllenberg. It is tracked as CVE-2020-14040.
Cheers,
Katie for the Go team
This make it easier to catch the issue during the compilation, also,
this also align with other plugins, i.e. plugin of "InterPodAffinity".
Signed-off-by: Dave Chen <dave.chen@arm.com>
This script quiently depended on being under a GOPATH, and failed
completely when it was not. This change sorts the input (to make
comparing results easier) and operates on files, rather than packages
until the last moment when we add back the package prefix.
Verified by instrumenting the code and comparing runs inside and outside
of GOPATH.
Before this commit, containers which have both a `startupProbe` and a
`readinessProbe` are marked as `ready=false` during stratup, but
containers which have only a `startupProbe` are marked `ready=true`.
This doesn't make sense.
This commit only considers readiness if the container is considered to
have "started", which leaves `ready=false` while starting up.
The behavior for exec'ing a backgrounded command is not specified
with CRI so modify the test to run the command directly instead
of using exec.
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
