-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow downgrade in cluster.spec.topology.version if machine deployments and controlplane versions have not been upgraded #9098
Comments
Not really. If we do it right they are all cached so it should take ~ microseconds. The problem is rather that its racy. But maybe that is something that we don't want to care too much about? |
Another option would be to add some sort of unsafe annotation and allow downgrades in general if it is present. Basically some signal that "I know what I'm doing" |
Yeah, that seems reasonable. |
I would assign this to myself, but i'll be going on PTO soon... |
@fabriziopandini WDYT about adding an annotation? |
In an offline conversation, I heard we're ok to proceed with this. Move to triage accepted? |
Yup!! /triage accepted |
(cc @fabriziopandini) |
+1 to using an annotation for this use case |
/assign @chrischdi This is part of #10063 |
What would you like to be added (User Story)?
As a developer I'd like to be able to downgrade cluster.spec.topology.version in cases where the topology reconciler has not updated the controlplane and machine deployment versions to the newer version.
Detailed Description
As a developer, I may end up in a state where I have some issues with my ClusterClass variables/patches such that I need to change the cluster.spec.topology.version to get back to a valid reconcile before upgrading again.
E.g., I have a patch that is dependent on builtin.controlplane.version, but I don't have variable data for the newer version yet. In this case, the topology reconciler fails to apply patches and reconciliation stalls.
My cluster isn't yet upgraded in reality and controlplane.spec.version and md.spec.version hasn't changed yet, since this occurs after json patches are calculated.
In this case, I should be able to downgrade the version without any side effect.
Anything else you would like to add?
This might be expensive, in terms of iterating over controlplane and md resources related to a cluster in the webhook?
Label(s) to be applied
/kind feature
/area api
The text was updated successfully, but these errors were encountered: