Helm package not found from stable repository on deployment

Legacy Containers
1

Cross-posting from Slack:

Hi there, I’m trying to configure an Octopus Cloud trial instance to deploy the Redis Helm package to our Kubernetes cluster. I’ve configured the public stable Helm feed as an External Feed in Octopus, and tests on that work fine: the Redis package (amongst others we use) can be found fine from the test page. When it comes to deploying a release of this, however, I see the following error message, and I’m wondering if I’ve mis-configured something, or if I’ve found a bug :thinking_face:

The step failed: Activity failed with error 'The package redis v6.4.5 could not be downloaded to the
package cache from Helm repository at https://kubernetes-charts.storage.googleapis.com after
making 1 attempts over a total of 4s. Make sure the package is pushed to the feed and try the
deployment again. For a detailed troubleshooting guide go to http://g.octopushq.com/TroubleshootMissingPackages
System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified at
System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at
System.Diagnostics.Process.Start(ProcessStartInfo startInfo) at
Octopus.Core.Packages.Helm.HelmCommandRunner.Invoke(String args, String dir, ILog log) at
Octopus.Core.Packages.Helm.HelmCommandRunner.Fetch(String url, String packageId, IVersion version, String directory, String username, String password, ILog log) at
Octopus.Core.Packages.Helm.HelmPackageFeed.DownloadPackageToLocalCache(String packageId, IVersion version, ITaskContext taskContext, LogContext logContext) at
Octopus.Core.Packages.DeploymentPackageDownloader.<>c__DisplayClass10_0.<DownloadPackage>b__0()'.

From my local machine, I can see the package version is definitely there:

> helm search redis
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION                     
stable/prometheus-redis-exporter        1.0.2           0.28.0          Prometheus exporter for Redis metrics
stable/redis                            6.4.5           4.0.14          Open source, advanced key-value store. It is often referr...
stable/redis-ha                         3.4.0           5.0.3           Highly available Kubernetes implementation of Redis
stable/sensu                            0.2.3           0.28            Sensu monitoring framework backed by the Redis transport

Any ideas? Thanks in advance

Alastair

3

Hi Alastair,

I think you are seeing this error because the Helm client is not installed on the machine that is running the deployment. The error message is misleading but the part “The system cannot find the file specified…” is actually referring to helm. I’ve opened an issue to clarify that message: https://github.com/OctopusDeploy/Issues/issues/5498

Hope this helps.

Cheers,
Shane

4

Brilliant, thanks @Shane_Gill! I wondered if that might be the case. This is an Octopus Cloud instance. I didn’t see any instructions on setting up Helm in this environment, so I figured it would be bundled in the deployed images. Have I missed something?

5

Hi Alastair,

At the moment cloud instances do not include Helm pre-installed because the Helm client version is tightly coupled to the Tiller server version. Octopus does not have the capability to manage multiple tooling versions, so odds are you would end up with a Helm that is not compatible with your server.

To run the Helm steps from your cloud instance you would need to setup a worker and install Helm on the worker. More information on workers can be found here: https://octopus.com/docs/infrastructure/workers.

We are working to make a better experience when a deployment requires specific tooling versions.

Cheers,
Shane

1 Like
6

Hi Alastair,

As an alternative to setting up a worker you may be able to install Helm during your deployment to the Octopus instance. Configure a script step that runs “On the Octopus Server” to check if Helm exists, if not install it. Note that cloud instances are transient, so the check for Helm would need to happen at the start of every Helm-related deployment.

Cheers,
Shane

7

Great stuff, thanks @Shane_Gill.

We are working to make a better experience when a deployment requires specific tooling versions.

FWIW, I expected to be able to deploy Tiller/helm init my cluster with a copy of helm built into Octopus, and to be able to update the copy of helm Octopus with a simple button click. (I’m thinking similar way to the way TeamCity allows you to manage NuGet.exe versions.)

8

Thanks Alastair, the description of your expectations is worth a lot to us. I’ve passed it on to our VP of Product, and to members of our containers and cloud teams. We’ll use it to shape our decisions and welcome your ongoing feedback as we flesh out the features that deal with tool-dependant deployments from cloud instances.

Cheers
Shane