Open sbueringer opened 5 months ago
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.
/priority backlog /kind cleanup
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.
+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)
Also xref PR which would get obsolete:
As of today MachineDeployments manage a history of MachineSet objects.
This feature roughly consists of:
This feature (afaik) has been mostly copied from k/k Deployments & ReplicaSets
Reasons why we should consider deprecation:
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.