Allow upgrades skipping minors for worker nodes #8616
Labels
area/clusterclass
Issues or PRs related to clusterclass
help wanted
Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
kind/feature
Categorizes issue or PR as related to a new feature.
priority/backlog
Higher priority than priority/awaiting-more-evidence.
triage/accepted
Indicates an issue or PR is ready to be actively worked on.
What would you like to be added (User Story)?
It would be great to have a better API/better automation for streamlined upgrades in managed topologies
Detailed Description
This KEP introduced the idea of streamlined upgrades, and, by playing around with K8s version skew policies, making it possible to upgrade by 2 or 3 Kubernetes minor versions by minimizing the worker's machines rollouts.
While streamlined upgrades with managed topologies are possible, the UX is not ideal, because it requires manually upgrading through all the minors and applying "topology.cluster.x-k8s.io/hold-upgrade-sequence" to the first MD till the target version is reached, but it should work.
We should improve managed topologies API/automation so we can allow users to trigger streamlined upgrades with a single CR change
Anything else you would like to add?
Disussion in #8614 could be relevant for defining the API for this issue
Label(s) to be applied
/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.
The text was updated successfully, but these errors were encountered: