helm: `release: not found` when I do `helm install` on a chart with some weird properties
Came across this while doing some mad science on directories that are both Helm charts and Javascript modules. Minimal repro case is here. The end result is that Helm successfully deploys a chart and immediately forgets that it did, like so:
> helm install --name test .
NAME: test
Error: getting deployed release "test": release: not found
It does actually create the relevant Deployment object, but it doesn’t know anything about the test release. I have to manually go in and delete the Deployment with kubectl.
I’m sure the problem is related to the node_modules directory – it contains a zillion files and directories for all of my Javascript dependencies. Potentially I’m exceeding some hidden limit for files allowed within a Helm chart? Obviously I should be putting node_modules in .helmignore, but presumably Helm should also be doing something more coherent upon this failure case.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 5
- Comments: 25 (7 by maintainers)
Commits related to this issue
- Add helmignore to avoid uploading useless files to tiller when deploying chart Some useless files, such as docs/*, will be uploaded to tiller when deploying Harbor chart, this will cause error https:... — committed to ywk253100/harbor-helm by ywk253100 6 years ago
- Add helmignore to avoid uploading useless files to tiller when deploying chart Some useless files, such as docs/*, will be uploaded to tiller when deploying Harbor chart, this will cause error https:... — committed to ywk253100/harbor-helm by ywk253100 6 years ago
- Add helmignore to avoid uploading useless files to tiller when deploying chart Some useless files, such as docs/*, will be uploaded to tiller when deploying Harbor chart, this will cause error https:... — committed to ywk253100/harbor-helm by ywk253100 6 years ago
- Add helmignore to avoid uploading useless files to tiller when deploying chart Some useless files, such as .git, docs/*, will be uploaded to tiller when deploying Harbor chart, this will cause error ... — committed to ywk253100/harbor-helm by ywk253100 6 years ago
- Add helmignore to avoid uploading useless files to tiller when deploying chart Some useless files, such as docs/*, will be uploaded to tiller when deploying Harbor chart, this will cause error https:... — committed to scottrigby/harbor-helm by ywk253100 6 years ago
I’d like to +1 the error message part. Ran into the same problem and had to figure out that the issue is a configmap (in my case one that didn’t get delete with
--purgefor whatever reason).Would it be possible to have a better error message for this? I had the same error
release: not found, and it took me a while to figure out that the problem was that there was too much data to fit in aConfigMap.I’m not familiar with the design of Helm and Tiller, but maybe there’s an easy way for Tiller to return this as a clear error message which Helm would show to the user?
I realize this is an old post and closed issue, but I wanted to share what I discovered as the cause of the over-sized configmap. Each time I issued a
helm package ./command, any previous versions of the package (*.tzg files) was included in the current one. The tgz package file kept growing, exponentially. The cure was to add*.tgzto the.helmignorefile.This looks like more than just bug relating to the error message. We have ConfigMaps that are nearly 1MB on their own and already contain compressed data. Kubernetes handles these without issue, but when helm combines them into a single ConfigMap it hits the Kubernetes limit.
The issue is magnified with sub-charts.
This also happens if your chart is at the root of the repo. Seems helm is packaging the .git repository. With the current error message, this is very hard to diagnose.
Adding .git and other non chart related directories and files to the
.helmignorefile fixes the problem.When you get bit, all the resources are left dangling, which violates the helm transaction.
+1 for updating this to a bug. I ran into the same problem. The charts were orphaned and i had to manually delete all the resources helm created and couldnt do a helm delete --purge
Can you get the output of Tiller’s logs using
kubectl? Also, if you dokubectl get configmap --namespace kube-system, do you see a config map with that release name (e.g.test)? THat’s where it stores its deployment record.This should be updated to be a bug. When this issue happens the user gets a bad error message and the chart installs get orphaned. If possible it would also be great to catch this prior to any kubernetes objects being installed or even by helm lint. In my specific case my chart is at the root of a git repo so a
helm package .shows me that it is packaging up the.gitfolder in the root of the repo which is why my chart ballooned to over 1M. My fix was of course to add a.helmignorefor.git, but I also have to manually clean up all resources created by the failedhelm installJust for others reference, you should just untar the chart to debug why its so big. My problem is that my charts stored previous versions of themselves.
Ah! So the chart is too large to get stored. IIRC, there’s a limit in Kubernetes 1.5 that no resource can be larger than (approximately) 1M. We do gzip the chart, but it probably still pushed beyond that limit.
EDIT: and you can use
.helmignore(like.gitignore) to prevent the Node stuff from getting pushed to Helm, which may fix this for you./remove-lifecycle rotten
Still relevant, helm should fail hard on the
install/upgradeif the chart is too big, rather than acting like it succeeds but not creating a release.Ah, looks like you got it, Tiller complains that it can’t create the ConfigMap: