helm: Question: I cannot depend on a chart which a dependency also depends on

I cannot depend on a chart safely which itself is a dependency of another chart that I depend on.

Steps to reproduce are encapsulated in the following bash script:

mkdir experiment
cd experiment
helm create a
helm create b
helm create c
mv c c-0.2.0
cat > c-0.2.0/Chart.yaml << CHART
apiVersion: v1
description: A Helm chart for Kubernetes
name: c
version: 0.2.0
CHART
helm create c
mv c c-0.1.0
cd b
cp -af ../c-0.1.0 charts
cd ../a
cp -af ../b charts
cp -af ../c-0.2.0 charts
helm install --debug .

This script yields the following result:

Error: release prodding-gecko failed: services "prodding-gecko-c" already exists

The above script illustrates the problem. Chart “C” comes in two versions: 0.1.0 and 0.2.0 . Chart “B” relies on chart “C” at version 0.1.0. Char “A” relies on chart “B” and also relies on chart “C” at version 0.2.0 . When I try to install chart “A”, it tries to install chart “C” twice, and the second installation fails, thus failing the deploy.

I understand that this problem can be gotten around by changing the “C” chart so that the version of the chart is also used in the k8s service name, but this requires potentially changing an upstream dependency. Further, this behavior is not the default, since helm create by default just uses the name of the chart to create the service name within the deployment.

This is the classic broken diamond dependency problem.

Understanding that this problem may not be solvable for helm, do you have any recommendations for how to deal with this?

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 3
Comments: 18 (1 by maintainers)

Most upvoted comments

I have the same problem and described it a little bit better in #3163. We don’t want to use a further tool…

benkeil on Dec 11, 2017

You’re on the right track 😀

Yes, I replaced requirements.yaml with degasolv.edn in my implementation.
Yes, B’s degasolv.edn has a reference to C and A’s degasolv.edn has a reference to B and C.
Currently, yes, it would only work for your company. However there may be something I can do to help you here.

I am the maintainer of the degasolv project. I could have “taught” degasolv to read requirements.yaml for projects but opted not to because it violates the semantics if that file. Maybe people write requirements.yaml files expecting for there to be two C packages installed.

Instead, I could start a degasolv repository on bintray with third party dependencies pre loaded for the atlas model. If you are interested in this you should email me at the degasolv-users Google group.

For a presentation and demo video I have look here https://bit.ly/degasolv2017pres

djhaskin987 on Oct 11, 2017

Perhaps this can be accomplished by changing {{ template "fullname" }} – by adding the name of any parent charts to it. Thus, for a release called prodding-gecko, {{ template "fullname" }} would yield "prodding-gecko-a-b-c" inside the A -> B -> C chart, and would yield "prodding-gecko-a-c" inside the A -> C chart.

To improve the solution’s backwards compatibility, we might just create a new template function called something like {{ template "chartqualifier" }} and make this the default instead of {{ template "fullname" }} when helm create is called.

Thoughts?

djhaskin987 on Sep 16, 2017