Helm having issues with properly resolving nested (duplicated) dependencies

[ED220-RitM]

Output of helm version:
version.BuildInfo{Version:"v3.14.4", GitCommit:"81c902a123462fd4052bc5e9aa9c513c4c8fc142", GitTreeState:"clean", GoVersion:"go1.21.9"}

Output of kubectl version: Shouldn't be relevant here, but
Client Version: v1.28.8
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3

Cloud Provider/Platform (AKS, GKE, Minikube etc.): not relevant

Issue:

We are having some base components (like services) defined in pre-defined charts that we are then using to build up more complex structures.

E.g.:
component-service: defines a kubernetes service resources with variable placeholders
component-quarkus: defines a lot of base setup (including deployment, poddisruptionbudget, ...), as well as include the above component for configuring a service
actual app repo: then uses component-quarkus and configures the quarkus deployment by eg providing image, env and some other configuration

Now we had the need to have more than one deployment in a single app repository.
The idea sounded simple: just add the component-quarkus chart twice as a dependency (with two different aliases), and configure them individually. But for some reason, helm is having issues resolving the template within the component-service within that, once the dependency is added twice.

Simplified Example:

component-inner

component-inner/templates/service.yml:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}
  namespace: {{ .Values.global.namespace | default "namespace" }}
  labels: {} # empty for mvp
spec:
{{- if .Values.type }}
  type: {{ .Values.type }}
{{- end }}
  ports:
  {{- range $k,$v := .Values.ports }}
    {{- if $v }}
    - name: {{ $k }}
      port: {{ tpl ( $v | toString ) $ }}
      protocol: TCP
      targetPort: {{ $k }}
    {{- end }}
  {{- end }}
  selector: {} # empty for mvp

component-inner/Chart.yaml:

apiVersion: v2
type: application
name: component-inner
version: 0.1.0
description: <insert description>

component-outer

component-outer/Chart.yaml:

apiVersion: v2
type: application
name: component-outer
version: 0.1.0
description: <insert description>
dependencies:
  - name: component-inner
    alias: inner
    version: 0.1.0
    repository: file://../component-inner

component-outer/values.yaml:

inner:
  ports:
    http: "8080"

app

app/Chart.yaml:

apiVersion: v2
type: application
name: app
version: 0.1.0
description: <insert description>
dependencies:
  - name: component-outer
    alias: outerone
    version: 0.1.0
    repository: file://../component-outer
  - name: component-outer
    alias: outertwo
    version: 0.1.0
    repository: file://../component-outer

app/values.yaml:

outerone:
  inner:
    type: someType

outertwo:
  inner:
    type: someType

Resulting template result of app, after resolving dependencies:

---
# Source: app/charts/outerone/charts/inner/templates/service.yml
apiVersion: v1
kind: Service
metadata:
  name: release-name
  namespace: namespace
  labels: {} # empty for mvp
spec:
  type: someType
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: http
  selector: {} # empty for mvp
---
# Source: app/charts/outertwo/charts/component-inner/templates/service.yml
apiVersion: v1
kind: Service
metadata:
  name: release-name
  namespace: namespace
  labels: {} # empty for mvp
spec:
  ports:
  selector: {} # empty for mvp

Observations:

• For the component, which is rendered second, neither the ports, nor the type are passed correctly
• the comment with the source in the final result shows that for the second service, the alias is ignored, and it is just using the inner component directly
• this behavior depends on the order of the dependencies defined in the Chart.yaml. If outerone and outertwo would be switched, then the other one would be rendered incorrectly
• when using two different versions of component-outer in the app, then the issue seems to be resolved (even though they still use the same version of the inner component)
• when referencing/using outertwo.component-inner.ports/type (as suggested from the result path) from app/values.yaml instead of the configured alias, then the properties are available in the actual template

Are we doing something wrong here? Or is this a bug with helm?

[gjenkins8]

Thanks for the detailed examples. From looking briefly, this does appear to be a bug. And if so, Helm is not correctly dealing with the aliases. I didn't get a chance to look in detail / reproduce.

One curiousity I see from the example output, is that the outerone chart is rendering the inner chart (as an alias). The outertwo chart is rendering as component-inner (the chart name).

[ED220-RitM]

One curiousity I see from the example output, is that the outerone chart is rendering the inner chart (as an alias). The outertwo chart is rendering as component-inner (the chart name).

Exactly. And as mentioned: the inner chart there can be properly configured by using the chart name (outertwo.component-inner). This is also the current workaround we are using

[ED220-RitM]

After reading through other issues again, it seems like this is related and/or referring to the same issue: #11484 which also has a MR attached: #12276

[maxnorth]

Hey, author of #12276 here. Would love to get that merged and resolve this, but not sure what it will take. Maybe the maintainers only merge fixes for bugs considered high priority 🤷.