Pre-proposal idea: introduce a new flag for helm uninstall "--fail-on-error" and a new release status "failed-uninstall"
mikeshngdev@...
Hi all, Following the HIP guide. I am looking for feedback regarding my idea below: https://github.com/helm/helm/blob/v3.4.2/pkg/action/uninstall.go#L122-L127 https://github.com/helm/helm/blob/v3.4.2/pkg/action/uninstall.go#L144-L150
https://github.com/helm/helm/blob/v3.4.2/pkg/action/uninstall.go#L81-L91 That's why I am sharing my idea of adding a new flag to helm uninstall "--fail-on-error". If this flag is enabled, and the helm uninstall completed with errors then update the release record to "failed-uninstall" status. |
|
Hi Mike,
This seems like it could be very useful, especially during dev where there are more likely to be issues in the uninstall of the resources. Keeping the release would allow would give us a starting point to work from to recover, as you mention in your idea. Being an opt-in strategy, remove adverse affects for those with processes that expect the existing behavior. Joshua Packer |
|
Joe Lanford
Big +1 from me!
When trying to automate chart uninstalls (e.g. in the context of operator-sdk's helm-operator), it is fairly unintuitive and complex to set things up in such a way to guarantee resource cleanup. Off the top of my head, the following must happen: 1. All uninstall attempts must set `--keep-history=true` 2. Prior to making each subsequent uninstall attempt, the latest release status must be set to something other than `Uninstalled`. |
|