Helm v3

[pszuster]

Hi! any plans to port to Helm v3? thanks!

[ljnelson]

Yes, absolutely. It will be slow in coming as it will need to be a full port by hand, now that the gRPC piece is gone. This is also a nights-and-weekends project so thanks in advance for your patience.

[jwlai]

Do you have a roadmap forward and would you be taking in developers to help? I'd like to offer some services as this is a useful tool that I'd like to leverage !

[ljnelson]

Hello; no, not really. This is a nights-and-weekends project so it goes slowly. I was also waiting for the immediate churn of the community migration from Helm 2 to Helm 3 to stabilize somewhat since unlike Helm 2 there can't be any generated code involved: this will have to be a full by-hand port in such a way that it will be easy to also port Helm bug fixes after the fact.

[theAkito]

So how's it going? I fear this tool sadly cannot be of much use when it takes forever for an upgrade. For now, it seems like this project is stuck 1 major version behind the current stable Helm version, if not worse.

Additionally, I am not sure what exactly you responded to, earlier.
Do you mean, that you do not want help?
If yes, why? Why does it have to go slowly, when this project could actually be really useful?

[geertp-ngdata]

@ljnelson I agree this is not an easy task. For helm v2, this was just another client for the gRPC server of Tiller.

For v3 you would actually have to completely port the Go code from helm to Java, not just the 'client' code. And then also continue to backport any changes in the Go code back to Java.

The alternative would be to run helm inside Kubernetes, and let it execute helm install/upgrades from inside Kubernetes.
This is exactly what https://github.com/fluxcd/helm-controller does.

If people still need a Java client, that would be a Kubernetes client that just deploys a HelmRelease CRD, and let the HelmController operator handle the rest.