DRA: automated upgrade/downgrade testing #132295
Conversation
This enables writing tests which manage the cluster startup themselves.
A special test (for example, one which manages its own cluster) could almost construct a Framework instance because most fields are exported. The `clientConfig` field isn't because REST configs often need to be deep-copied to avoid accidentally updating some shared copy, so for this special case a SetClientConfig is needed.
The test brings up the kind cluster and uses that power to run through upgrade/downgrade and version skew scenarios. Several tests can run in parallel because each cluster is independent, but inside the test the steps have to be sequential. It is debatable whether this should be an E2E test at all. Technically this could also be an integration test. It's currently done mostly for pragmatic reasons: - It can reuse the existing helper code. - It can run in the normal DRA E2E jobs, with timeouts defined there. - Integration tests are limited to 10 minutes per directory and pull-kubernetes-integration is already a big and slow job. A different approach for per-SIG or per-feature integration testing would be needed. The new helper code for managing a kind cluster is written so that it could be used both in an integration test and an E2E test. kubernetes#122481 could make that a bit easier in an E2E test, but is not absolutely required.
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
release-note-none
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
needs-triage
github-project-automation
bot
added this to
SIG Node CI/Test Board and SIG Node: code and documentation PRs
k8s-ci-robot
added
sig/testing
github-project-automation
bot
moved this to Triage
in SIG Node: code and documentation PRs
k8s-ci-robot
added
the
wg/device-management
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pohly The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
size/XL
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Promotion of any feature, in this case core DRA to GA, depends on (so far) manually testing the upgrade/downgrade path. It's hard to document what exactly was tested in a way that others can verify the procedure and/or replicate it.
This PR adds helper packages for upgrading/downgrading a kind cluster and running E2E tests against, and uses that to test some DRA scenarios. It runs as part of the normal e2e.test invocation in pull/ci-kubernetes-kind-dra.
Which issue(s) this PR is related to:
#128965
KEP: kubernetes/enhancements#4381
Special notes for your reviewer:
It is debatable whether this should be an E2E test at all. Technically this could also be an integration test. It's currently done as E2E test mostly for pragmatic reasons:
The new helper code for managing a kind cluster is written so that it could be used both in an integration test and an E2E test. #122481 could make that a bit easier in an E2E test, but is not absolutely required.
Does this PR introduce a user-facing change?