Closed hiromu-a5a closed 1 month ago
/triage accepted
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
/priority backlog
Let's keep this on hold until the discussion on https://github.com/kubernetes-sigs/cluster-api/issues/10479 is sorted out
Community agreed on deprecation for revision management, so also clusterctl alpha rollout undo is going away /close
@fabriziopandini: Closing this issue.
What would you like to be added (User Story)?
As an operator I'd like to validate the Kubernetes version skew policy when I run
clusterctl alpha rollout undo
.Detailed Description
The existing clusterclt rollout undo command might violate the version skew policy easily and accidentally. For example, if a user has MachineSet (revision=1, k8s version=1.22) and MachineSet (revision=4, k8s version=1.25) and mistakenly triggers rollback from revision 4 to 1, there's no way to stop it. I'd like to suggest that clusterctl raises an error if users break the version skew policy and allow the operation only if a user sets --force option.
Anything else you would like to add?
Possible Concerns and Solutions:
rollout
and makes negative impact on the existing end users.version
field is empty.--force
option?--force
options rather than interactive-mode.Related issue: #3439
Label(s) to be applied
/kind feature /area clusterctl