Auto install Tiller to enable Helm Chart deployments via Weave Cloud

[ngehani]

Current situation:

We support Helm charts but cannot deploy them unless Tiller is installed. Tiller is not installed by default so the user has to go figure out and get that installed first before they can use Weave Cloud to deploy Helm charts.

We should:

Have a way to auto install “Tiller” or simplify this as part
of our on-boarding and not have the user jump out and figure out how
to get Tiller installed out of band, if they are using Weave Cloud for
Helm Charts.

Flow:

1. When Deployment of a helm chart is triggered, check to see if Tiller is installed
2. Notify user that Tiller is not installed and do they want to install it? Yes/no
3. If yes, Weave Cloud should install it for them and continue their deployment without them starting over.
4. Keep the Tiller installed by default
   Optional:
5. They can manually uninstall it using our launcher?
6. They can manually install it using our launcher.

[lilic]

In my opinion the user will most likely choose the Helm install option if they already are familiar with Helm or even more likely if they have Helm installed in their cluster.

Have a way to auto install “Tiller” or simplify this as part
When Deployment of a helm chart is triggered, check to see if Tiller is installed

I don't agree, as the reason why people would choose Helm is to use the helm cli and it is also because they tend to trust Helm install options more.

[ngehani]

if they already are familiar with Helm or even more likely if they have Tiller installed in their cluster.

You mean using Helm install vs curl install option? Is that live? If they use helm install option, would it automatically deploy Tiller? How many people choose helm install option? For people that don't (#), then what (instrumented?)?

don't agree, as the reason why people would choose Helm is to use the helm cli and it is also because they tend to trust Helm install options more.

Couldn't same have been said for kubectl? If they use helm cli then why would they need our Deploy (flux) to deploy helm charts too? How many people use curl vs helm for installing?

[ngehani]

Depending on when Helm v3 comes out, this may be moot :-) but I suspect that's a long way off.

[dlespiau]

tl;dr; it's complicated

My hunch is that is helm is beyond what we should be responsible for installing on the cluster. At some point we need to draw a line around launcher responsibilities.

• Making the decision to install helm tiller seems closer to a cluster provisioning tool, eg. it'd be an addon specified in clusterctl,
• Where do we stop? installing a database in the cluster seems too much for instance, we have to define a line.
• It adds more maintenance burden on us instead of leaving decisions to cluster users. For instance what happens when helm 3 is out? helm 3 has no tiller (https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md)
• The current proposed flow adds more more step to the install process.
• Giving a preferential treatment to helm is debatable.

[ngehani]

Making the decision to install helm tiller seems closer to a cluster provisioning tool, eg. it'd be an addon specified in clusterctl,

If we are building a clusterctl, then sure, it can be part of that. It doesn't matter where it is. It does matter that we remove friction at every point. If we are connecting to a cluster and there is no cluster then we provision that cluster with whatever means necessary. Making it available via the UI is something I believe should be available in the App Homepage (that's a separate issue though).

If we support deploying helm charts and then realize that we can't, because the user has not enabled it. We need to remove that friction as well since it's a dependency for the user to use this feature.

[ngehani]

@dlespiau What's your thinking on when helm v3 will be ready?

[dlespiau]

Unfortunately, I don't have a crystal ball either :)

[lilic]

Considering there is no roadmap for helm 3, I doubt anytime soon? https://github.com/helm/helm/milestones

My hunch is that is helm is beyond what we should be responsible for installing on the cluster.

👍 +1

I understand the point you are making @ngehani , but we would be making a lot of assumptions about the users cluster and needing them to have helm installed anyways like we do for kubectl already now. I would even suggest we switch back to installing via kubectl as one of the options... :)

[ngehani]

I would even suggest we switch back to installing via kubectl as one of the options... :)

Too many options adds cognitive load. We need to pick one and use it. Can we replace our "curl" with just using "helm"? I presume as part of this is to check to see if helm is enabled and if not, ask to enable it, and then default to using curl if the answer is no so the user doesn't have to do it, we are doing it for them. I get Error: helm command not found when I execute the below - nothing else, no help in telling me what I should do next. No info on pre-requisites before I run this command. All of this is friction to the user.

[lilic]

Too many options adds cognitive load.

I wouldn't say that, you always have different options when installing tools, helm, curl, different package managers, etc. options are good, we can default to the "standard" way but giving options IMO is a good idea.

Can we replace our "curl" with just using "helm"?

IMHO no. As not everyone agrees with Helm and would not want it installed in their cluster for various reasons (security, preferences, etc.)

The helm install goes through helm so yes we can't send feedback back to the UI if the install fails for any reason. We could add some docs to that page maybe, pointing to helm? WDYT?