Daniel Lipovetsky

Another note: When [Atomic](https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm//blob/4aa8c43993dd8530b483b7b42cfcaf98cb4cb372/api/v1alpha1/helmchartproxy_types.go#L138-L141) is enabled, the helm client will try to uninstall/rollback if it hits an error during install/upgrade. When that happens, the release state changes to[ `uninstalling`](https://github.com/helm/helm/blob/ef85fa7f2ddc0a7a810007e283846c123f486748/pkg/release/status.go#L35) or...

We recently [talked about this behavior](https://kubernetes.slack.com/archives/C8TSNPY4T/p1718293737907399) in #cluster-api slack.

To address (a), I propose a specialized "strict" client that follows the pattern established by the specialized "field owner" client introduced in #2771

/cc @erkanerol

On a related note, there is an [ongoing conversation in Kubernetes slack](https://kubernetes.slack.com/archives/C04JFT7GDGR/p1699492799557699?thread_ts=1681728672.112079&cid=C04JFT7GDGR) with CAPVCD maintainers about whether the InfraMachine controller should impose the condition described above.

> I think it's already doable if you implement the MachineDeletionPhaseHook https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20200602-machine-deletion-phase-hooks.md#changes-to-machine-controller Thanks for this helpful context! I amended my feature request to explain why I think Cluster API should...

I think there are two obvious deletion strategies. Feel free to suggest others, or alternate names for these. 1. Graceful. Drain a Node before deleting its corresponding Machine. 2. Forced....

In summary, I think supporting a _Graceful_ strategy may make sense, but it won't address problem that motivated this idea. I'm fine with waiting to see what the community thinks....

Please see the [proposal](https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/5678) PR for a separate NodeadmConfig.

Thanks to everyone for working together to solve this :bow: