Nested null values do not remove keys from sub-charts

[rodrigoechaide]

Nested null values do not remove keys from sub-charts.

I have the following setting in a sub-chart:

fluentd:
  livenessProbe:
    httpGet: null
    tcpSocket:
      port: 24224
    initialDelaySeconds: 20
  readinessProbe:
    httpGet: null
    tcpSocket:
      port: 24224
    initialDelaySeconds: 20

After running the helm template command, I still have the httpGet default values for the readiness and liveness probes. I want to remove them because otherwise, Kubernetes will reject the installation of the chart. It is not possible to configure more than one readiness and liveness probes kind simultaneously.

Output of helm version:

version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.21.4"}

Output of kubectl version:

Client Version: v1.25.4
Kustomize Version: v4.5.7

The following issues are related:

• Nested null values do not remove keys from sub-charts #9136
• Nested null values don't remove keys as expected #5184

I don't know why they are closed if the problem still persists.

[francostellari]

I observed the same issue in Helm v3.13.2

Client Version: v1.25.3
Kustomize Version: v4.5.7
Server Version: v1.26.9+636f2be

My Chart.yaml contains:

dependencies:
- name: postgresql
  version: "13.1.5"
  repository: "oci://registry-1.docker.io/bitnamicharts"

My parent values.yaml contains:

postgresql:
  primary:
    extendedConfiguration: "max_connections=1000"
    priorityClassName: system-node-critical
    podSecurityContext:
      fsGroup: null
      seccompProfile:
        type: RuntimeDefault
    containerSecurityContext:
      runAsUser: null
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      seccompProfile:
        type: RuntimeDefault
      capabilities:
        drop: [ "ALL" ]
  volumePermissions:
    enabled: false
  shmVolume:
    enabled: false

Yet the yaml generated with a --dry-run still contains the fsGroup: 1001:

      securityContext:
        fsGroup: 1001 # <<<<<<<<<<
        seccompProfile:
          type: RuntimeDefault

and

            runAsGroup: 0
            runAsNonRoot: true
            runAsUser: 1001 # <<<<<<<<
            seccompProfile:
              type: RuntimeDefault

[pdettori]

Same problem here. Cannot remove keys seting to null a subchart value.

[francostellari]

I just checked that the issue is still present in the just released Helm
version.BuildInfo{Version:"v3.13.3", GitCommit:"c8b948945e52abba22ff885446a1486cb5fd3474", GitTreeState:"clean", GoVersion:"go1.20.11"}

[hamelg]

I have this issue with these helm version embedded in my argocd-repo-server :
version.BuildInfo{Version:"v3.11.2", GitCommit:"5307b09986704410394ccdae24e40933db4a9a0b", GitTreeState:"", GoVersion:"go1.19.13"}
ersion.BuildInfo{Version:"v3.12.0", GitCommit:"c9f554d75773799f72ceef38c51210f1842a1dea", GitTreeState:"clean", GoVersion:"go1.20.4"}

[rptaylor]

This has been reported many times (e.g. #12488), but apparently not acknowledged or noticed as a bug yet. I assume you're using --values or -f.

Although this issue may be yet another duplicate of #12488 I would recommend keeping it open so hopefully someone will notice this problem.

[sabre1041]

@rptaylor would like to note that it is indeed a valid outstanding issue

[Reamer]

Definitely a big step backwards. Thank you for your detailed bug report. I have downgraded my Argo CD version because I need this functionality.

[rptaylor]

As noted in the linked issue a workaround is to overwrite the default values.yml file instead of specifying a different location with --values or -f.

[lplazas]

Definitely a big step backwards. Thank you for your detailed bug report. I have downgraded my Argo CD version because I need this functionality.

What version did you downgrade to?

[Reamer]

Definitely a big step backwards. Thank you for your detailed bug report. I have downgraded my Argo CD version because I need this functionality.

What version did you downgrade to?

At the moment I am on https://github.com/argoproj/argo-cd/releases/tag/v2.9.1

https://github.com/argoproj/argo-cd/releases/tag/v2.9.2 has updated helm in MR argoproj/argo-cd#16344.

[Hoid]

This is a pretty significant blocker for us being able to use helm to deploy our app in production like we planned. Will this be fixed in 3.14.3, the next release on March 13, or at least prioritized for a upcoming release?

[pisto]

Unfortunately, devs don't seem to realize that this bug forces everybody who is affected by this bug to fork the subcharts to fix such a "small" problem. It already happens way too often that one is forced to fork upstream charts, because of bad choices or limitations in the templates, however it would be great if this bug wasn't yet another reason that forces you to fork.

In some cases you may be in luck and you may be able to workaround the problem with helm-x (helm + kustomize), or helmfile (which integrates helm-x), but that's even more tooling. These are also not an option when using ArgoCD or Rancher, just to name two.

[atmask]

Can confirm I encountered this on helm 3.13. Had to downgrade to work around

[zsolt-marta-bitrise]

Seeing something similar here #12991

Works if we set the dependent object value to empty string "" instead of null btw