7f87629a3f
Dropping the error that is returned by allocateOne hides the reason *why*
allocation failed. Including the UID is "too much information" for an error
message (usually the user doesn't care about the exact identity, just the name)
and the claim name can and will be added by the caller.
Before:
controller.go:373: E0625 16:04:12.140953] test-driver.cdi.k8s.io/resource controller: processing failed err="claim test-dramq9jv-resource-h72pg: failed allocating claim 8551afba-3c9a-4a8a-8633-6fad6c4b9e42" key="schedulingCtx:test/test-dramq9jv"
event.go:377: I0625 16:04:12.141031] test-driver.cdi.k8s.io/resource controller: Event(v1.ObjectReference{Kind:"PodSchedulingContext", Namespace:"test", Name:"test-dra65gfw", UID:"6be9ba57-31da-4fef-b61d-b0468d71afcf", APIVersion:"resource.k8s.io/v1alpha3", ResourceVersion:"197", FieldPath:""}): type: 'Warning' reason: 'Failed' claim test-dra65gfw-resource-zpzrj: failed allocating claim f98a32e1-ab7d-4b34-a258-6d8224aa9006
After:
controller.go:373: E0625 16:02:54.248059] test-driver.cdi.k8s.io/resource controller: processing failed err="claim test-dram98ll-resource-nvsbj: device selectors are not supported" key="schedulingCtx:test/test-dram98ll"
event.go:377: I0625 16:02:54.248163] test-driver.cdi.k8s.io/resource controller: Event(v1.ObjectReference{Kind:"PodSchedulingContext", Namespace:"test", Name:"test-dratpt77", UID:"24010402-b026-4fe4-a535-e1dab69db8c0", APIVersion:"resource.k8s.io/v1alpha3", ResourceVersion:"298", FieldPath:""}): type: 'Warning' reason: 'Failed' claim test-dratpt77-resource-vlgrv: device selectors are not supported
Overview
The tests in this directory cover dynamic resource allocation support in Kubernetes. They do not test the correct behavior of arbitrary dynamic resource allocation drivers.
If such a driver is needed, then the in-tree test/e2e/dra/test-driver is used, with a slight twist: instead of deploying that driver directly in the cluster, the necessary sockets for interaction with kubelet (registration and dynamic resource allocation) get proxied into the e2e.test binary. This reuses the work done for CSI mock testing. The advantage is that no separate images are needed for the test driver and that the e2e test has full control over all gRPC calls, in case that it needs that for operations like error injection or checking calls.
Cluster setup preparation
The container runtime must support CDI. CRI-O supports CDI starting from release 1.23, Containerd supports CDI starting from release 1.7. To bring up a Kind cluster with Containerd, two things are needed:
NB: Kind switched to use worker-node base image with Containerd 1.7 by default starting from release 0.20, build kind from latest main branch sources or use Kind release binary 0.20 or later.
Build kind node image
After building Kubernetes, in Kubernetes source code tree build new node image:
$ kind build node-image --image dra/node:latest $(pwd)
Bring up a Kind cluster
$ kind create cluster --config test/e2e/dra/kind.yaml --image dra/node:latest
Run tests
- Build ginkgo
$ make ginkgo
- Run e2e tests for the
Dynamic Resource Allocationfeature:
$ KUBECONFIG=~/.kube/config _output/bin/ginkgo -p -v -focus=Feature:DynamicResourceAllocation ./test/e2e