MachineDeployment history should also track in-place propagating changes

ykakarap commented 1 year ago

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.

fabriziopandini commented 1 year ago

/triage accepted /help

k8s-ci-robot commented 1 year ago

@fabriziopandini: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

Why are we solving this issue?
To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
Does this issue have zero to low barrier of entry?
How can the assignee reach out to you for help?

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.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/8392): >/triage accepted >/help Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

sbueringer commented 1 year ago

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)

vincepri commented 1 year ago

The above might be a use case that’s better solved by external tools like gitops

fabriziopandini commented 6 months ago

/priority backlog

kubernetes-sigs / cluster-api