-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Open
Labels
area/clusterclassIssues or PRs related to clusterclassIssues or PRs related to clusterclasskind/featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.Must be staffed and worked on either currently, or very soon, ideally in time for the next release.triage/acceptedIndicates an issue or PR is ready to be actively worked on.Indicates an issue or PR is ready to be actively worked on.
Description
Tracking issue for #12199
- ✨ Implement core logic for chained upgrades #12726 (including fields in CC and refactoring the E2E tests)
- Follow-up: ⚠️ Improve chained upgrade observability #12973
- conditions in general: audit relevant parts in
topology/cluster/conditions.go, we should also especially surface it in conditions if the newly introduced hooks are blocking - audit logs for correctness in desired_state.go (e.g. the versions we log)
- ensure we send the right versions in hooks
- conditions in general: audit relevant parts in
- Follow-up: Add additional validation in Cluster/ClusterClass webhook: [help wanted] (@Karthik-K-N)
- Cluster webhook: ClusterClass rebase: check that new ClusterClass includes .spec.topology.version (if CC has versions)
- ClusterClass webhook: on create/update: ensure versions of all Clusters using that ClusterClass are included in ClusterClass versions (if CC has versions)
- Follow-up: 🌱 Allow >1 minor version upgrades if generateUpgradePlan extension is defined #12979
- Follow-up: ⚠️ Improve chained upgrade observability #12973
- Integration with Runtime Extension [help wanted] (@sivchari)
- Add
.spec.upgrade.external.generateUpgradePlanExtensionfield to ClusterClass: ✨ Add .spec.upgrade.external.generateUpgradePlanExtension field to ClusterClass #12809 - Add GenerateUpgradePlanRequest/GenerateUpgradePlanResponse types + GenerateUpgradePlan hook ✨ Add types and hook for GenerateUpgradePlan #12823
- Call GenerateUpgradePlan Runtime Extension in desired_state.go: ✨ Call GenerateUpgradePlanRequest Runtime Extension #12903
- Implement GenerateUpgradePlan in test/extension: ✨ Implement GenerateUpgradePlan handler #12927
- Add corresponding e2e test coverage: ✨ Change RuntimeSDK e2e test ClusterClass to use GenerateUpgradePlan extension #12955
- Double check instructions in comment below
- Add
- New lifecycle hooks (@fabriziopandini)
- Add hooks types, change existing hooks where required ✨ Add lifecycle hooks for chained-upgrade #12878
- Implement hooks calls: ✨ Call new lifecycle hooks for chained-upgrades #12891
- Extend e2e test, including
TODO(chained-upgrade): FP, we can't check next CP upgrade doesn't start, it starts immediately(ideally we have e2e test coverage for all upgrade hooks)
- Extend e2e test, including
- Make the AfterClusterUpgrade hook blocking for the next upgrade: ⚠️ Make the AfterClusterUpgrade hook blocking #12984
- "Testing"
- Brainstorm about edge cases
- Think through all permutations of setting Kubernetes versions / external.upgrade on CC (and which ones we cover in e2e tests)
- Test chained upgrade without workers: ✨ Call new lifecycle hooks for chained-upgrades #12891 (comment)
- Go through a few upgrade flows (desired state + upgrade plan) (either just by looking through the code or with the debugger)
- Brainstorm about edge cases
- Misc
- Audit
TODO(chained-upgrade) - Ensure strict sequencing for all hooks except AfterControlPlaneInitialized (i.e. we have to wait for hook completion before continuing), Also take a look at reentrancy and see if we can improve it with a reasonable complexity trade-off (e.g. mark as pending:
AfterControlPlaneUpgrade)
- Audit
- Documentation
- Update lifecycle hook documentation in the book
- Sync & check against the proposal that everything was either implemented or is tracked in a follow-up issue
Next release:
- Consider if to add more info about version(s) in status
- Consider performance optimizations for topology controller (specifically also for lifecycle hook calls), e.g. rate-limiting
- Introduce util to deduplicate Machine version checks in RuntimeSDK e2e test: ✨ Call new lifecycle hooks for chained-upgrades #12891 (comment)
- Follow-up: Update desired_state_test.go for new replica fields (e.g. remove unavailableReplicas)
- Follow-up: Improve
GetUpgradePlanFromClusterClassVersionsalgo: ✨ Implement core logic for chained upgrades #12726 (comment) - Follow-up: Reduce dependency tree for util patch ⚠️ Make the AfterClusterUpgrade hook blocking #12984 (comment)
Metadata
Metadata
Assignees
Labels
area/clusterclassIssues or PRs related to clusterclassIssues or PRs related to clusterclasskind/featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.Must be staffed and worked on either currently, or very soon, ideally in time for the next release.triage/acceptedIndicates an issue or PR is ready to be actively worked on.Indicates an issue or PR is ready to be actively worked on.