Failed Helm releases require manual user intervention to recover

[michaelgeorgeattard]

Given:

• A working Helm release backed by a HelmRelease resource
• Values in HelmRelease are changed in a way that Helm upgrade fails
• Flux is synced with GitOps, causing Helm upgrade to fail
• Values in HelmRelease are reverted to valid state
• Flux is synced with GitOps

In the above scenario, Flux Helm Operator complains that the helm release already exists and to manually delete (purge it).

As Flux uses GitOps flow, cluster state should have fully recovered after the last step.

This feels like a bug; I can provide more details, replication steps if needed.

[hiddeco]

Flux Helm Operator complains that the helm release already exists and to manually delete (purge it).

This should no longer happen, given #2008 (>=0.9.0)

As Flux uses GitOps flow, cluster state should have fully recovered after the last step.

There already is an issue for rollbacks: #1960 (being worked on in #2006), including an explanation on why we can not enable it by default for every HelmRelease.

[kingdonb]

Please let me know if you still need help with this. I apologize for the staleness of this reply, we are in the process of cleaning up stale issues from the Flux v1 repo now, this should be over soon.

I will close the issue for now as it is stale. Flux v1 remains in maintenance mode.

We can provide support to Flux v1 users especially with respect to migrating to the new Flux version, Flux v2, which has some breaking changes but is also a total rewrite and also brings many improvements. I'm closing the issue but you are most welcome to write back on this issue, or open another issue. Thanks for using Flux.