https://datahubproject.io logo
Join Slack
Powered by
Has anyone run into an error with DataHub v0.7.1 i...
# all-things-deployment
w
Has anyone run into an error with DataHub v0.7.1 in which the dependent charts in 
datahub-kubernetes
fail to identify the dependent charts such as 
datahub-gms
? We are pushing the datahub chart to a chart museum and when attempting to deploy that chart into our K8's cluster, I’m getting an error like this:
Copy code
resource-helm>>> Updating dependencies in /tmp/build/put/stg-chart/datahub...
Saving 5 charts
Save error occurred:  directory charts/datahub-gms not found
l
@early-lamp-41924 ^
w
seems to happen when just running 
helm dep up datahub
in the datahub-kubernetes folder:
Copy code
$ helm dep up --debug datahub
Repository from local path: file://./charts/datahub-gms
Repository from local path: file://./charts/datahub-frontend
Repository from local path: file://./charts/datahub-mae-consumer
Repository from local path: file://./charts/datahub-mce-consumer
Repository from local path: file://./charts/datahub-ingestion-cron
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "spothero" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 5 charts
Archiving datahub-gms from repo file://./charts/datahub-gms
Save error occurred:  directory datahub/charts/datahub-gms not found
Deleting newly downloaded charts, restoring pre-update state
Error: directory datahub/charts/datahub-gms not found
helm.go:94: [debug] directory datahub/charts/datahub-gms not found
<http://helm.sh/helm/v3/internal/resolver.GetLocalPath|helm.sh/helm/v3/internal/resolver.GetLocalPath>
	/home/circleci/helm.sh/helm/internal/resolver/resolver.go:193
<http://helm.sh/helm/v3/pkg/downloader.tarFromLocalDir|helm.sh/helm/v3/pkg/downloader.tarFromLocalDir>
	/home/circleci/helm.sh/helm/pkg/downloader/manager.go:690
<http://helm.sh/helm/v3/pkg/downloader.(*Manager).downloadAll|helm.sh/helm/v3/pkg/downloader.(*Manager).downloadAll>
	/home/circleci/helm.sh/helm/pkg/downloader/manager.go:273
<http://helm.sh/helm/v3/pkg/downloader.(*Manager).Update|helm.sh/helm/v3/pkg/downloader.(*Manager).Update>
	/home/circleci/helm.sh/helm/pkg/downloader/manager.go:172
main.newDependencyUpdateCmd.func1
	/home/circleci/helm.sh/helm/cmd/helm/dependency_update.go:73
<http://github.com/spf13/cobra.(*Command).execute|github.com/spf13/cobra.(*Command).execute>
	/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:842
<http://github.com/spf13/cobra.(*Command).ExecuteC|github.com/spf13/cobra.(*Command).ExecuteC>
	/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:950
<http://github.com/spf13/cobra.(*Command).Execute|github.com/spf13/cobra.(*Command).Execute>
	/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:887
main.main
	/home/circleci/helm.sh/helm/cmd/helm/helm.go:93
runtime.main
	/usr/local/go/src/runtime/proc.go:203
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:1373
this is with helm version 
version.BuildInfo{Version:"v3.3.0", GitCommit:"8a4aeec08d67a7b84472007529e8097ec3742105", GitTreeState:"dirty", GoVersion:"go1.14.7"}
e
@white-beach-27328 bc the datahub chart uses local subcharts, you shouldn’t run 
helm dep update
Just running helm install in the directory should work
the command is failing because the chart files are under the chart directory which is also used by helm dep update to put tarballs.
since we use local subcharts, we don’t need the tar balls
w
ah ok
is the reason those charts are specified as dependencies then so that condition values can be used to enable/disable charts?
i
Alternative: If you rename the folder charts to anything else and update the dependency paths in Chart.yaml it should work. I did this on my local copy a while ago because we have automatic deployment pipelines based on helm
e
Yes
I was actually about to do that and push to master
but thought maybe some people depend on it
w
I tried to do the rename and ran into a different issue where it wasn’t able to find the correct version for some reason
Our internal build tools update dependencies no matter what which I could try to modify. However, it was easier to just delete the sub charts we weren’t using (the 
cron
chart) and eliminate the dependencies in the main chart given that they’re already provided.
I was wondering if decoupling the charts from one another would reduce friction with build and deployment systems (i.e. each chart could be deployed independently). You could replace the 
condition
’s with just an if statement on the resources. Sometimes these dependency systems are brittle and add more complexity than they’re worth. Major downside would be that it makes things less DRY. Just something I was thinking about doing for our deployment.
e
Sorry about the late reply. This is a good idea. I also felt like this was unnecessary before and the enabling part was the blocker. Do you mind sending out a PR for this?
Open in Slack
PreviousNext
Powered by