Think twice before using Helm
Bartłomiej Antoniak
56811

Hi,

this article is very well written and the first time I encountered:
Error: UPGRADE FAILED: "foo" has no deployed releases

I just thought… ok this guy really puts lots of effort into it and didn’t found a solution and nobody else does.

Now this happened to me a second time with my most critical platform chart, which actually does manage namespaces, roles, rights, ingress controller, storageclasses, …

So deleting this chart, would mean, removing all charts which rely on that, which are pretty much all.

So I had to fight through it and I did.

Basically most of the time, it seems, that we all are using Helm wrong, which actually means, the UX of Helm is terrible when something unexpected happens.

Because most of the time a helm rollback <chart> <current_version -1>
fixes the problem and you can deploy the fixed version again.

This time I messed up everything, so I had to:
• edit configmaps of the last failed release
• set state to DEPLOYED
• do a helm upgrade
• This will update the helm list but most properly the new release will also be in state Failed
• Do a helm rollback to the current_release -1
• Do a regular helm upgrade

I guess Helm would be much better, when it would rollback on its own, when a deployment went wrong (including the removal of all resources deployed during this release), but there were so many discussions about this in the Helm project I completely lost the current state.