Open ykakarap opened 1 year ago
/triage accepted /help
@fabriziopandini: This request has been marked as needing help from a contributor.
Please ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help
command.
I think we have to really balance if the additional complexity this would introduce in the MD/MS controller is justified by user demand. (Especially given that demand for clusterctl rollout seems to be not that great)
The above might be a use case that’s better solved by external tools like gitops
/priority backlog
What would you like to be added (User Story)?
As a user I would like track changes to a MachineDeployment in the MD's history. Currently on changes that cause a rollout are captured in the history (as separate MachineSets). As a user I would like MachineDeployment to also track changes to in-place propagating fields.
Detailed Description
Changes to some of the in-place propagating fields could change the properties of the underlying nodes. Example: changes to
MachineDeployment.Spec.Template.Lables
could change the labels on the underlying nodes.Therefore it would be nice to be able to capture these changes in MachineDeployment history so that as a user I can rollback to the previous state, using
clusterctl alpha rollout undo
if necessary.Anything else you would like to add?
Additional context:
This will primarily benefit classic clusters. For classy clusters, it is not currently possible to rollback to a previous state using clusterctl as the MachineDeployment is managed by cluster topology.
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.