Add Helm template support

[dippynark]

It'd be great if this controller could support simply templating a chart and handling the resulting resources as if they had been applied with a Kustomization. This would help resolve many of the reliability issues related to this controller, for example:

• Not cleaning up resources after failed deletion
• Getting stuck after failed rollback
• Getting stuck if shut down during an install/upgrade/rollback

[makkes]

This sounds like you're advocating against the use of Helm for anything but templating. You can already do this by runninghelm template yourself, push the resources to a Git repository and create an accompanying GitRepository and Kustomization.

[dippynark]

Yeah exactly, but generating locally does not work well for multiple clusters unfortunately; if I have 1000 clusters that each use a Helm chart templated with cluster specific values coming from some Secret/ConfigMap (containing the domain used by the cluster, for example), then this would require storing 1000 copies of the manifests with the slight templated variations.

[hiddeco]

This is not going to be a part of the helm-controller, as its scope is to work like Helm, and not as a helm template | kubectl apply -f - executor.

If you need that, you can always write your own controller that watches a HelmChart source object, and runs the logic whenever it notices a change of revision.

[hiddeco]

I want to add that I have noticed your comments about the current way the helm-controller does state determination, which is part of some of the issues you describe at the beginning.

I already made this observation myself a couple of months ago, and have plans to improve this in the near future. The problem is that at times it is difficult to reliably make observations on what Helm is doing, or has done.

My way around this is going to be an observing storage wrapper that always gives us access to the release object that is the result of actions made by the helm-controller. Which should make making observations a lot easier.

[dippynark]

Ah yeah that makes - might look into implementing something like that as I reckon it'd be quite powerful and simpler operate, but happy to have this issue closed in that case.

Yeah I think a lot of the difficulty is just dealing with how Helm works (e.g. Helm will refuse to upgrade if a previous upgrade gets interrupted). We have a number of Deployments watching for these kinds of errors and kicking the controller back into action, but we need to be careful not to orphan resources by doing this, so interested to try this work when it's ready!