Open lentzi90 opened 4 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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.