Support Helm 3.x

[okamototk]

Helm 3.x is alpha yet. But it's not use tiller and architecture is quite different than Helm 2.x.

Could you support Helm 3.x also?

[prydonius]

Thanks @okamototk, this is certainly on the roadmap, though since Helm 3 is only in alpha right now we don't have a timeline for when we'll support it.

[lindhe]

It's in Beta now. Anything on the roadmap?

[andresmgot]

it's definitively in our roadmap but we don't have a date yet (the beta is still being tested)

[lindhe]

I'm glad to hear that it's on the roadmap. It just so happens that the project I'm in would have great use for having Helm 3 support in Kubeapps. So my team would like to dedicate resources during the next few weeks to implement this, unless you strongly disagree. We would be able to give it at least 2 or 3 people full time during 3 weeks, but probably more if needed.

We understand that it cannot be fully realized before Helm 3 is stable, but we think the beta is stable enough to at least begin the effort. We have been trying out the Helm 3 beta, and even started contributing to it actually.

However, it is always a daunting task to dig into someone else's code base. So we would very much appreciate some assistance from you during the development. You've been great to work with so far, during our brief encounters here on Github.

Please tell us your thoughts on this.

---

Oh, and sorry for dropping the ball in #1119 during the summer. We had to get the go-ahead from our customer in order to contribute Opensource code, and that took longer than we expected. But we're good to go now, so we hope to pick that up soon. :) But we would like to give priority to implementing support for Helm 3.

[andresmgot]

That's great to hear @lindhe :) We haven't had the time to play with Helm 3 yet so if you already have experience with that it will be great. We are more than happy to assist with anything needed. If you need a more synchronous communication, we are in the #kubeapps channel in the Kubernetes slack (https://slack.k8s.io/).

As you may know from your work in #1119, the current communication between Kubeapps and Tiller is made through the service called tiller-proxy. The idea would be to maintain the same REST API but use the new Helm 3 client libraries to resolve charts and deploy them. In a nutshell, what this service does is:

• Get some chart info as part of the body of the request.
• Resolve the chart.
• Validate that the user has permissions to perform the required action using the k8s Authorization API.
• Perform the installation/upgrade/deletion.

Once you are able to play around, it would be helpful if you submit a small proposal to https://github.com/kubeapps/kubeapps/tree/master/docs/architecture/design-proposals with the possible implementation so we can discuss/agree in a solution before moving forward and submit code.

Let us know what you think.

[lindhe]

That sounds like a good way forward. I suspected to hear a suggestion along those lines. In fact, the tiller proxy is one of the reasons that I see this a surmountable task -- I think that was a good design choice.

One aspect that I think we will have to discuss further is the configuration management of multiple users. I'm a bit worried that we'll encounter difficulties with multiple logged in users that all need to have different kubectl configs. But we will take that discussion when we know more details.

We'll keep you posted here and in the Slack channel, along with a design proposal once we get that far.

Our next sprint begins in 7 days, so that's when we expect to start any actual work on it. FYI, our team is me (@lindhe), @latiif , @NiclasWarefelt and @SimonAlling.

[prydonius]

FYI some changes might need to be made to chartsvc too in order to support the new Helm 3 format, though I'm not clear on what those are yet. xref helm/monocular#649

[absoludity]

Just my 2c - I've not been involved as long as Andres, but while thinking about this recently (see #1175) I noted that, given that tiller-proxy will currently error if it cannot connect to tiller, we could:

• Add a switch to tiller-proxy: -use-helm3 which initially defaults to false so the current behaviour is maintained by default,
• When -use-helm3=true tiller-proxy does not talk to tiller at all but uses the helm3 API instead (and we do not need to do any user permission checks as we'll be using the users credentials)

With this switch, Kubeapps can continue to support both helm2 and 3 for the mean-time, albeit in separate deployments [1]. When helm3 should be the default for new deploys, we can switch the default of use-helm3 to true to reflect that, while still allowing users to run with helm2 explicitly. Later again we can remove the helm2 support. And somewhere in there, rename tiller-proxy->backend [2]

Thoughts?

[1] I don't see a need for being able to support both in a single Kubeapps deployment, though could be missing something?
[2] Even after switching to helm3 completely and removing helm2 support, having transitioned tiller-proxy to a backend service will be useful long-term for improving authz, but that's a separate discussion.

[andresmgot]

That's a valid approach. I am just not sure if it's worth to maintain the possibility of using the two different versions of Helm in the same service. Maybe it's easier to start "from scratch" (copying the interesting parts) and create a different microservice. Then through chart options we could deploy one version of the service or the other. I say service (or backend as you name it) instead of tiller-proxy because that name may not make sense anymore.

[1] I don't see a need for being able to support both in a single Kubeapps deployment, though could be missing something?

There will be some charts that are only installable with Helm 2 and not Helm 3 and vice versa but probably that's something that we don't need to support.

[absoludity]

That's a valid approach. I am just not sure if it's worth to maintain the possibility of using the two different versions of Helm in the same service.

Yeah, though the point I was trying to make is that there would seem to be close to zero cost (for the approach itself), smaller than the cost of maintaining two separate services, imo. But let's see. Looking forward to reading more!

[1] I don't see a need for being able to support both in a single Kubeapps deployment, though could be missing something?

There will be some charts that are only installable with Helm 2 and not Helm 3 and vice versa but probably that's something that we don't need to support.

+1

[andresmgot]

We can consider this done now :) The next release that is in progress will have support for Helm 3