[bitnami/redis] Problems with "common.labels.standard" updating from 17.15 to 17.17

Tansito commented 11 months ago

Name and Version

bitnami/redis 17.17.1

What architecture are you using?

A chart with sub-charts and dependencies. In this case redis is being managed as dependency:

https://github.com/Qiskit-Extensions/quantum-serverless/pull/899/files#diff-b33ed2caec010f904c1e2afcc995f529ccd30420791f2bcc61476b71da3494f9

What steps will reproduce the bug?

1.- Updating redis package from 17.15.2 to 17.17.1, related pull request: https://github.com/Qiskit-Extensions/quantum-serverless/pull/899 2.- Running helm lint --with-subcharts 3.- Generates an error that didn't appear in 17.15.2 version. Error related with:

==> Linting charts/quantum-serverless
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: template: quantum-serverless/charts/redis/templates/master/service.yaml:12:14: executing "quantum-serverless/charts/redis/templates/master/service.yaml" at <include "common.labels.standard" (dict "customLabels" .Values.commonLabels "context" $)>: error calling include: template: quantum-serverless/charts/keycloak/charts/common/templates/_labels.tpl:6:27: executing "common.labels.standard" at <include "common.names.name" .>: error calling include: template: quantum-serverless/charts/keycloak/charts/common/templates/_names.tpl:6:18: executing "common.names.name" at <.Chart.Name>: nil pointer evaluating interface {}.Name

Are you using any custom parameters or values?

Our current values.yaml for our redis sub-chart is the next one:

redis:
  nameOverride: "redis"
  fullnameOverride: "redis"

  architecture: "standalone"
  global:
    redis:
      password: ""
  auth:
    enabled: false

You can check our complete values file configuration here.

What is the expected behavior?

We would expect to have the same output running helm lint than in the previous 17.15.2 version.

What do you see instead?

The output that we obtain is the next one:

==> Linting charts/quantum-serverless
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: template: quantum-serverless/charts/redis/templates/master/service.yaml:12:14: executing "quantum-serverless/charts/redis/templates/master/service.yaml" at <include "common.labels.standard" (dict "customLabels" .Values.commonLabels "context" $)>: error calling include: template: quantum-serverless/charts/keycloak/charts/common/templates/_labels.tpl:6:27: executing "common.labels.standard" at <include "common.names.name" .>: error calling include: template: quantum-serverless/charts/keycloak/charts/common/templates/_names.tpl:6:18: executing "common.names.name" at <.Chart.Name>: nil pointer evaluating interface {}.Name

Additional information

Pull request with the update of this version: https://github.com/Qiskit-Extensions/quantum-serverless/pull/899
Link to the Chart.lock from that pull request: https://github.com/Qiskit-Extensions/quantum-serverless/blob/787a8918d16c2264f14bf8361b85f9dc11f9421d/charts/quantum-serverless/Chart.lock
Our quantum-serverless chart uses sub-charts and is managed by dependencies: https://github.com/Qiskit-Extensions/quantum-serverless/tree/main/charts/quantum-serverless

juan131 commented 10 months ago

Hi @Tansito

This is a consequence of importing charts that make use of different versions of the bitnami/common library. As you can see on this issue, when several charts have the same library chart as dependency but using different versions, the same template is declared twice with the same name but you can't tell which one will be loaded last and, therefore, used.

The Redis chart is trying to use a library in bitnami/common that was evolved on recent versions and it's very likely there's another chart loading a different version that's not compatible with the way Redis wants to use it.

Could you please share your Chart.lock?

Tansito commented 10 months ago

Hi @juan131 , I see! That makes sense, this ir our .lock for that update:

https://github.com/Qiskit-Extensions/quantum-serverless/blob/787a8918d16c2264f14bf8361b85f9dc11f9421d/charts/quantum-serverless/Chart.lock

If I understood you well, you recommend us then update all bitnami charts at once to avoid conflicts with bitnami/common, don't you?

juan131 commented 10 months ago

Yes @Tansito ! That's the best way to ensure the bitnami/common library used is compatible with all the charts.

Tansito commented 10 months ago

Perfect! Thank you for the support, @juan131. We will take a look and let you know if we have problems with the update then. Feel free to close the issue, I can open another one if we continue having the problem 🙏

juan131 commented 10 months ago

Awesome! Please let us know if you find issues again.

bitnami / charts