Remove revision management in MachineDeployments

[sbueringer]

As of today MachineDeployments manage a history of MachineSet objects.

This feature roughly consists of:

• Keeping a number of old MachineSets around (can be configured via MD.spec.revisionHistoryLimit)
• Re-using old MachineSets if after a MachineDeployment update the Machine templates of MD and MS match again
• Tracking revisions and revision history via annotations on MD and MS objects
• corresponding clusterctl commands: clusterctl alpha rollout, see also: clusterctl rollout #3439
  • most notable the rollout undo command which allows to rollback to a previous revision of the MachineDeployment

This feature (afaik) has been mostly copied from k/k Deployments & ReplicaSets

Reasons why we should consider deprecation & removal:

• As far as we are aware it is barely used by CAPI users and it leads to a lot of complexity in the MD controller (i.e. it makes it hard to introduce new features, like when we introduced the label/annotation in-place propagation). Indicators that it's barely used:
  • the corresponding clusterctl alpha rollout command is still alpha
  • we barely get any questions / requests about the entire feature
• It's not usable with GitOps
• It's highly recommended to have a history of YAMLs applied to a management cluster. With that it's easy to rollback. For clean operations that's already required for all objects apart from MachineDeployments (e.g. Cluster, KCP, InfraCluster, ...)
• It's almost not usable without clusterctl (at least it's relatively complicated to use)
• It's not usable with ClusterClass
• In a lot of cases it's not safe to rollback (e.g. after Kubernetes upgrades)

So overall I think considering the current state of the feature, it's interoperability and that it's as far as we can tell not really used we should really consider if it's worth the complexity and otherwise consider deprecation.

If you are using the feature, please let us know.

Edited Nov 27th 2024: Deprecation was done in 1.8, now it is about removal

[k8s-ci-robot]

This issue is currently awaiting triage.

CAPI contributors will take a look as soon as possible, apply one of the triage/* labels and provide further guidance.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fabriziopandini]

/priority backlog
/kind cleanup

[enxebre]

As consumer I think beyond the clusterctl rollout exposure we could say revisionHistoryLimit is actually more of an implementation detail and the same functionality can be achieved by rolling out forward towards any config.
As a provider/admin/SRE the only drawback I can think of is that we lose a mean to introspect history of a MachineDeployment for troubleshooting purposes. Overall I think deprecation probably adds more value (sustainability) than it takes.

[fabriziopandini]

+1 to deprecate an remove.
There so many open questions and the interest around this feature is very low (+ we have very few clusterctl maintainers left)

[chrischdi]

Also xref PR which would get obsolete:

• ⚠️ Enforce version skew policy in rollout undo #8567

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

/lifecycle frozen

[fabriziopandini]

Deprecation was done in 1.8, now it is about removal

[chrischdi]

/assign @sbueringer