WaitForPod*() are just wrapper functions for e2epod package, and they
made an invalid dependency to sub e2e framework from the core framework.
So this replaces WaitForPodRunning() with the e2epod function.
TestDispatchingBookmarkEventsWithConcurrentStop can use processEvent
instead of `dispatchEvent` to avoid data race conditions with
`Cacher.watchersBuffer`.
We have been having issues with making builds reproducible, especially
with the `.note.go.buildid` ELF section. One tip from a golang issue was
to set `-ldflags=-buildid=` which seems to work well. You can confirm
that the buildid is set to empty by inspecting the binaries with the go
command example `go tool buildid _output/local/go/bin/kubectl`
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
When creating an informer, this adds a way to add custom error handling, so that
Kubernetes tooling can properly surface the errors to the end user.
Fixes https://github.com/kubernetes/client-go/issues/155
So multiple instances of kube-apiserver can bind on the same address and
port, to provide seamless upgrades.
Signed-off-by: Mateusz Gozdek <mateusz@kinvolk.io>
containerMap is used in CPU Manager to store all containers information in the node.
containerMap provides a mapping from (pod, container) -> containerID for all containers a pod
It is reusable in another component in pkg/kubelet/cm which needs to track changes of all containers in the node.
Signed-off-by: Byonggon Chun <bg.chun@samsung.com>
As this is a a local object reference from a global object, referencing a ConfigMap would not be possible. Controller specific custom resources are a much better fit here, allowing for better validation.
This builds on previous work but only sets the sysctlConnReuse value
if the kernel is known to be above 4.19. To avoid calling GetKernelVersion
twice, I store the value from the CanUseIPVS method and then check the version
constraint at time of expected sysctl call.
Signed-off-by: Christopher M. Luciano <cmluciano@us.ibm.com>
do a conversion from the cgroups v1 limits to cgroups v2.
e.g. cpu.shares on cgroups v1 has a range of [2-262144] while the
equivalent on cgroups v2 is cpu.weight that uses a range [1-10000].
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
