Files
kubernetes/test/e2e_dra/README.md
Patrick Ohly d44d0281eb DRA upgrade/downgrade: rewrite as Go unit test
tCtx.Run and sub-tests make it much simpler to separate the different steps
than with Ginkgo because unless a test runs tCtx.Parallel (which we don't do
here), everything runs sequentially in a deterministic order.

Right now we get:

    ...
        localupcluster.go:285: I1210 12:24:22.067524] bring up v1.34: stopping kubelet
        localupcluster.go:285: I1210 12:24:22.067548] bring up v1.34: stopping kube-scheduler
        localupcluster.go:285: I1210 12:24:22.067570] bring up v1.34: stopping kube-controller-manager
        localupcluster.go:285: I1210 12:24:22.067589] bring up v1.34: stopping kube-apiserver
    --- PASS: TestUpgradeDowngrade (94.78s)
        --- PASS: TestUpgradeDowngrade/after-cluster-creation (2.07s)
            --- PASS: TestUpgradeDowngrade/after-cluster-creation/core_DRA (2.05s)
            --- PASS: TestUpgradeDowngrade/after-cluster-creation/ResourceClaim_device_status (0.02s)
        --- PASS: TestUpgradeDowngrade/after-cluster-upgrade (4.10s)
            --- PASS: TestUpgradeDowngrade/after-cluster-upgrade/core_DRA (4.09s)
            --- PASS: TestUpgradeDowngrade/after-cluster-upgrade/ResourceClaim_device_status (0.01s)
        --- PASS: TestUpgradeDowngrade/after-cluster-downgrade (1.24s)
            --- PASS: TestUpgradeDowngrade/after-cluster-downgrade/core_DRA (1.21s)
            --- PASS: TestUpgradeDowngrade/after-cluster-downgrade/ResourceClaim_device_status (0.02s)
    PASS

It's even possible to use `-failfast` and
e.g. `-run=TestUpgradeDowngrade/after-cluster-creation/core_DRA`: `go test` then
runs everything up to that sub-test or any failing sub-test, then stops and
cleans up.

(cherry picked from commit de47714879)
2026-01-16 07:54:51 +01:00

2.0 KiB

This directory contains a testsuite with automatic upgrade/downgrade tests for DRA. Conceptually this is like an integration test, in the sense that it starts/stops cluster components and runs tests against them. It has its own directory because it needs to be started differently than other integration tests or unit tests, which makes it more like an E2E suite.

The difference is that it starts Kubernetes components by running the actual binaries, relying on local-up-cluster.sh for the logic and configuration steps. local-up-cluster.sh needs additional permissions and preparations on the host.

To run it:

  • Make sure that hack/local-up-cluster.sh works:

    • sudo must work
    • Set env variables as necessary for your environment.
  • Ensure that /var/lib/kubelet/plugins, /var/lib/kubelet/plugins_registry, and /var/run/cdi are writable.

  • Build binaries with make.

  • Export KUBERNETES_SERVER_BIN_DIR=$(pwd)/_output/local/bin/linux/amd64 (or whatever is your GOOS/GOARCH and output directory).

  • Optional: export KUBERNETES_SERVER_CACHE_DIR=$(pwd)/_output/local/bin/linx/amd64/cache-dir to reuse downloaded release binaries across test invocations.

  • Optional: set ARTIFACTS to store component log files persistently. Otherwise a test tmp directory is used.

  • Invoke as a Go test (no need for the ginkgo CLI), for example:

      go test -v -count=1 -timeout=1h ./test/e2e_dra
      dlv test ./test/e2e_dra -- -test.v
      make test KUBE_TIMEOUT=-timeout=1h WHAT=test/e2e_dra FULL_LOG=true KUBE_TEST_ARGS="-count=1"
    

make test instead of make test-integration is intentional: local-up-cluster.sh itself wants to start etcd. -count=1 ensures that test runs each time it is invoked. -v/-test.v/FULL_LOG=true make the test output visible while the test runs.

To simplify starting from scratch, ./test/e2e_dra/run.sh cleans up, sets permissions, and then invokes whatever command is specified on the command line:

 ./test/e2e_dra/run.sh go test ./test/e2e_dra