Specifying local helm dependency - kubernetes-helm

I am trying to add a rabbitmq service using a bitnami helm chart. the chart contains one dependent helm chart which is called common.
The whole application itself is deployed using a parent helm chart and each service has its own separate helm chart.
the Helm chart structure looks like this-
\myapp
\charts
\service1
\service2
\service3
\messaging
\charts
\common
\templates
\chart.yml
\values.yml
When i ran "helm dependency update" from the 'messaging' dir, it downloaded a common-1.x.x.tgz file. i extracted the contents and placed it in the \messaging\charts\common folder
the original messaging\templates\chart.yml (rabbitmq helm chart) contained the following entry
dependencies:
- name: common
repository: https://charts.bitnami.com/bitnami
tags:
- bitnami-common
version: 1.x.x
because i cannot download during the "Helm install" execution i had to download the dependent helm charts beforehand and save them as a local dependency. After downloading the common.tgz file, i extracted the contents and updated the dependencies in the messaging\templates\chart.yml as follows
dependencies:
- name: common
repository: 'file://charts/messaging/charts/common'
tags:
- bitnami-common
version: 1.x.x
If i do "helm install messaging ." from \myapp\charts\messaging directory, the service gets deployed without any error. But when the application's parent helm chart is deployed i always get this error
"Error: found in Chart.yaml, but missing in charts/ directory: messaging"
Can someone please point out the mistake in the configuration? I moved around the contents of the common folder around multiple location, had them as tgz file, updated the repository path relative to the messaging directory instead of parent helm chart location, but in all cases, the installation of the messaging service fails with the above error

You don't need to unpack the charts/*.tgz file. If they're in that directory (and still packed up) then Helm will use them to run the deployment. Helm won't contact the external chart repository on its own, only when you run the helm dependency commands.
After you run helm dep up your filesystem layout should look like
myapp
\-- charts
\-- messaging
+-- charts
| \-- rabbitmq-8.15.3.tgz
|-- templates
| +-- deployment.yaml
| \-- service.yaml
+-- Chart.yaml
\-- values.yaml
You're ready to go in this state. Don't unpack anything.
If you need to copy this setup across a network boundary, include the charts/*.tgz files when you do it. It doesn't matter that Chart.yaml or requirements.yaml references an Internet location; helm install will only use those local archives.

I had a similar issue and it was because a developer had placed the Charts and templates etc in the charts directory. I kept getting errors saying it couldn't find directories so moved all the charts into a helm-charts directory instead as the charts directory is managed by Helm. When I updated the repository listing to pull from the new directory, my issue was resolved. I got the idea from this issue's comments and it worked. https://github.com/helm/helm/issues/2887

Related

How to make sure subcharts charts are installed before the actual resources

I am trying to create a helm based operator and for most part, I've got it working. However I need to make sure that the subcharts are installed before the operator is trying to create resources from those subcharts. For e.g I have mongodb community-operator helm chart as a subchart. However, when I deploy the operator i get the below error
failed to install release: unable to build kubernetes objects from release manifest: resource mapping not found for name: "test-mongodb" namespace: "default" from "": no matches for kind "MongoDBCommunity" in version "mongodbcommunity.mongodb.com/v1"
ensure CRDs are installed first.
Looks like its trying to create the mongodb instance before actually installing the operator and crds. How can I force it to first install the subcharts and then try to create mongodb instance.
inside the chart.yaml you can use the condition & tag
dependencies:
- name: subchart
version: 0.0.1
repository: https://chart.github.io/helm-charts
condition: subchart.enabled
so if the chart name as subchart is not installed already in cluster it will throw the error.
Official doc : https://helm.sh/docs/chart_best_practices/dependencies/
if you have multiple sub charts as dependencies you can also go with the tags

Helm upgrade command is not working as expected

When I run " helm upgrade ." , new modified changes in dependencies list are not updating.
Process we followed : Post doing required changes to the existing values file in helm chart, packaging it using "helm package ." and pushing packaged tar to s3 using s3 plugin.
In the another parent helm chart, we are mentioning above packaged tar file details like name,version and s3 repository link under dependencies list in requirements.yaml file.
successfully executing the helm dependency update also .
later, when executing helm upgrade it is showing like
client.go:229: [debug] checking 38 resources for changes
client.go:512: [debug] Looks like there are no changes
Helm unable to identify the new changes made to the dependencies list.
Please help to fix issue

Updating Helm subcharts fails without a clear error

While trying to add/update a dependency to a helm chart I'm getting this error. No helm plugins are installed with the name helm-manager.
$ helm dep update
Getting updates for unmanaged Helm repositories...
...Unable to get an update from the "https://kubernetes-charts.storage.googleapis.com/" chart repository:
failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden
...Unable to get an update from the "https://kubernetes-charts.storage.googleapis.com/" chart repository:
failed to fetch https://kubernetes-charts.storage.googleapis.com/index.yaml : 403 Forbidden
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. Happy Helming!
Error: no cached repository for helm-manager-1067d9c6027b8c3f27b49e40521d64be96ea412858d8e45064fa44afd3966ddc found. (try 'helm repo update'): open /Users/<redacted>/Library/Caches/helm/repository/helm-manager-1067d9c6027b8c3f27b49e40521d64be96ea412858d8e45064fa44
afd3966ddc-index.yaml: no such file or directory
The stable and incubator repositories of the Helm charts have been moved to a new location.
You must updated URI in charts.yaml (or requirements.yaml) to point to the new repositories in order to let the Helm dependency resolver find the correct location.
Name
Old Location
New Location
stable
https://kubernetes-charts.storage.googleapis.com
https://charts.helm.sh/stable
incubator
https://kubernetes-charts-incubator.storage.googleapis.com
https://charts.helm.sh/incubator
After that you should be able to run helm dep update without further modifications.
I get this sometimes when there's a mismatch between my Chart.yaml and the configuration of my subchart dependencies.
For instance:
Chart.yaml:
dependencies:
- name: foo
...
- name: bar
...
values.yaml:
foo:
flag: true
# but no entry for bar
It may be an artifact of some other element of my configuration (Artifactory hosting a proxy of the world for Helm) but I find myself running into this frequently enough that I hope this answer may help someone else.

Error: found in Chart.yaml, but missing in charts/ directory: mysql

I have added mysql in requirements.yaml. Helm dependency downloads the mysql chart
helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "nginx" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading mysql from repo <our private repository>
Deleting outdated charts
But when I do helm install my_app_chart ../my_app_chart
It gives error
Error: found in Chart.yaml, but missing in charts/ directory: mysql
You don't have to add it to the control version system, you just download them again if for some reason you have lost them (for example when you clone the repository). To do this, execute the command:
helm dependency update
The above command will download the dependencies you've defined in the requirements.yaml file or dependencies entry in Chart.yaml to the charts folder. This way, requirements are updated and you'll have the correct dependencies without worrying about if you updated them also in the control version system.
I updated .helmignore
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/
charts/
It contained charts/ I removed the entry and it worked
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/
I have encountred the same error message when I first started learning how to use libcharts, I used chart.yaml to specify the dependency of the libchart like so:
chart.yaml
...
dependencies:
- name: mylibchart
version: 0.1.0
repository: file://path/to/libchart
and in that libchart chart.yaml data was like this:
apiVersion: v2
name: lib <-- this was causing the error to occur (should be mylibchart instead)
description: A Helm chart for Kubernetes
type: library
version: 0.1.0
appVersion: "1.16.0"
so as you can see the name specified in the dependencies has to be the same name of the chart/libchart.

Is there a way to use Helm 3's new library charts without needing to involve `helm dependency update`?

The use case is as follows:
overall-concern/
charts/
cloudformation-chart/
kubernetes-chart/
shared-library/
Both the Cloudformation and Kubernetes charts rely on the shared library. If I specify
it as a dependency in those charts, however, I need to do helm dependency update and
it will be copied into those charts' charts/ subdirectory and a Chart.lock file will
be generated. That seems unnecessary.
On the other hand, if I symlink the chart:
overall-concern/
cloudformation-chart/
charts/
shared-library -> ../../shared-library
It works, but I receive a warning when running helm template that there are symlinks
in the path, leading me to think that this is not intended or is otherwise deprecated:
walk.go:74: found symbolic link in path: ... (paths elided) ...
Is there a blessed solution that will let me use a local chart without treating it as
a formal "dependency" in Helm 3?