-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
E2E: Use kind cluster for clusterctl upgrade tests #2098
Comments
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten I'm back and hoping to work on this soonish |
Traditionally, the clusterctl upgrade tests created a workload cluster to be used as secondary management cluster, with the old versions deployed. From that cluster, another workload test cluster was created to check that the old versions worked, before upgrading and finally verifying that the upgraded versions worked.
Creating two workload clusters in this way is quite resource intensive compared to how all the other tests use kind for management and only create a single test cluster.
CAPI has now made it possible to use kind also for the secondary management cluster! We should adopt this as it will lower the resource requirement and potentially allow us to dump parallelism to 2 for our optional tests.
The text was updated successfully, but these errors were encountered: