-
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
CAPI controllers should add finalizers into templates if the templates are necessary for updates. #6588
Comments
This has been already addressed with ClusterClass and managed topologies |
Isn't it still a valid use case to not use ClusterClass? |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
What I was trying to explain (sorry if I did not provide context) is that ClusterClass and managed topologies are already an answer to this use case because when using this feature the system takes care of managing template rotation for the users/the tool triggering the change. Given that, I don't think we need to implement another solution to the same problem (and ClusterClass and managed topologies solve much more than this problem). |
@fabriziopandini From my point of view, any controller should add a finalizer into a custom resource if the controller requires that custom resource to proceed when the custom resource is deleted. This rule must be followed by each controller in the dependency hierarchy/tree regardless of use cases. |
/triage accepted I'm not 100% sold on the idea of forcing finalizers on objects managed by the users (while instead we are already doing something similar when using managed topologies) /help |
@fabriziopandini: GuidelinesPlease 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 In response to this:
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. |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
We have a similar problem with infrastructure MachineTemplate. We use helm to deploy machine template. In order to update MachineDeployment according to instructions we add a checksum to the MachineTemplate name, but when changing the name helm removes the previous MachineTemplate and capi-controller skip processing MachineSet with "Not found" error and machines keep in the cluster. The only way for us is to use Another option. We are now migrating from Machine controller manager to ClusterApi. |
/priority backlog |
/triage accepted |
What steps did you take and what happened:
Changes in KubeadmConfigTemplate don't trigger any rollout #4910.
To be able to update the config, you need to create a new KubeadmConfigTemplate and update the reference in MachineDeployment. If you delete the existing KubeadmConfigTemplate, capi controller cannot complete the update.
What did you expect to happen:
capi-controller should add finalizers into templates if they are necessary to roll out some changes.
Anything else you would like to add:
Clients are responsible for declaring the desired state and I think storing old templates is not one of the clients' responsibilities. If controllers need to have a CR for any functionality, they should put their finalizers into resources to prevent any problematic deletion.
For the clients designed in a declarative way (e.g. gitops + flux, helm), it is tough to complete an update in one move. In the current design, we have to do some hacks like adding our own finalizers into templates and cleaning with our custom operator or doing upgrades in two moves. Both of them are so problematic.
Environment:
kubectl version
): v1.22.9/etc/os-release
):/kind bug
The text was updated successfully, but these errors were encountered: