27a68aee3a introduced context support for events. Creating an event
broadcaster with context makes tests more resilient against leaking goroutines
when that context gets canceled at the end of a test and enables per-test
output via ktesting.
The context could get passed to the constructor. A cleaner solution is to
enhance context support for the apiserver and then pass the context into the
controller's run method. This ripples up the call stack to all places which
start an apiserver.
We have "-kube-test-repo-list" command line flag to override the image registry. If we store it in global variable, then that overriding cannot take effect.
And this can cause puzzling bugs, e.g.: containerIsUnused() function will compare incorrect image address.
- The feature is GA so there's no feature gate so it doesn't need any
special label now.
- The test is not dual-stack-specific, so it shouldn't claim to be.
- It asserted node-IP-assigning behavior that is not guaranteed to
work on all clouds. (Among other things: that there are no "extra"
InternalIPs, and that there are InternalIPs of every supported IP
family, rather than there only being ExternalIPs of some families.)
Single-stepping interactively through a test can be useful to understand what's
happening and to investigate the state at each step.
Similar support was added early to hack/ginkgo-e2e.sh, so the same env variable
is used again.
In commit 2f426fdba6 we added
compatibility (and tests) to deal with pre-1.20 checkpoint files.
We are now well past the end of support for pre-1.20 kubelets,
so we can get rid of this code.
Signed-off-by: Francesco Romani <fromani@redhat.com>
Since 43539c855f (first released in
v1.30.0-alpha.2), the test/e2e/framework manages -v and -vmodule and uses them
for a logger which writes to the Ginkgo output stream.
This did not work for test/e2e_node, because:
- logs.AddFlags(pflag.CommandLine) registers its own -v and -vmodule flags
- pflag.CommandLine.AddGoFlagSet(flag.CommandLine) skips the corresponding
flags in the flag.CommandLine
- pflag.Parse() initializes the settings in the "logs" package even though
those are not used at runtime
The solution is to not use the "logs" package.
Fixed `The phase of Pod e2e-test-pod is Succeeded which is unexpected`
error. `e2epod.NewPodClient(f).CreateSync` is unable to catch 'Running'
status of the pod as pod finishes too fast.
Using `Create` API should solve the issue as it doesn't query pod
status.
The runtime classes are apiserver's concept, while the handlers are kubelet's concept.
For NodeStatus, it makes more sense to return the latter ones here.
This commit modifies the following files:
- pkg/apis/core/types.go
- staging/src/k8s.io/api/core/v1/types.go
- pkg/kubelet/nodestatus/setters.go
- pkg/kubelet/kubelet_node_status.go
- pkg/registry/core/node/strategy.go
- test/e2e_node/mount_rro_linux_test.go
Other changes were auto-generated by running `make update`.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
During the PR to get "Forensic Container Checkpointing" enabled in
containerd the decision was made to not correctly report if containerd
cannot find the CRIU binary. The reason was that the e2e_node checkpoint
test did not understand the error message.
The e2e_node checkpoint test is skipped if the container runtime (CRI-O
or containerd) does not enable checkpoint support of if checkpoint
support is not implemented.
This commit adds another reason to skip a check. If the underlying OS
which is used to test "Forensic Container Checkpointing" in combination
with containerd or CRI-O is missing the CRIU binary.
This was encountered on Google's Container-Optimized OS (COS) based
tests where CRIU was not installed.
With this change merged it is possible for containerd to return the
correct error message without breaking Kubernetes e2e tests.
Signed-off-by: Adrian Reber <areber@redhat.com>
The information is received from the DRA driver plugin through a new gRPC
streaming interface. This is backwards compatible with old DRA driver kubelet
plugins, their gRPC server will return "not implemented" and that can be
handled by kubelet. Therefore no API break is needed.
However, DRA drivers need to be updated because the Go API changed. They can
return
status.New(codes.Unimplemented, "no node resource support").Err()
if they don't support the new ListAndWatchResources method and
structured parameters.
The controller in kubelet then synchronizes this information from the driver
with NodeResourceSlice objects, creating, updating and deleting them as needed.
