helm: Could not delete default keys from subcharts if subchart is defined in dependencies

Two years after this seemingly simple bug report was originally opened, we are still waiting on a fix and https://github.com/helm/helm/pull/11440 now appears to be stalled.

This issue is such pain in the ass. Please fix it asap.

Running into this issue as well, we deploy all our stuff with ArgoCD via helm dependencies and this is really makes some deployments impossible

quick and dirty workaround until #11440 gets merged: run helm with

--post-renderer=grep --post-renderer-args=-v --post-renderer-args=': null$'

Hopefully it’s obvious why this is a pretty risky option; since it’s just a regex and not actually parsing the yaml, it will also affect things like block-formatted string values with lines that happen to end with : null (for example, a configmap containing a yaml file that is supposed to have a null value in it). If this is your use case, you could probably put together an appropriate yq command to use instead of grep. You can also reduce the risk by narrowing down the expression, for example if you’re just getting bitten by this bug because of null resources.limits.cpu values, you could use cpu: null$ as the expression instead.

Note to maintainers: please don’t take the existence of workarounds like this as evidence that this is not a high-priority issue! If anything, the relative jankiness of workarounds users are resorting to should serve to emphasize the importance of fixing this.

Using Helm version.BuildInfo{Version:"v3.10.2", GitCommit:"50f003e5ee8704ec937a756c646870227d7c8b58", GitTreeState:"clean", GoVersion:"go1.18.8"} and the Traefik 20.3.0 chart as a dependency. I can’t remove traefik.updateStrategy.rollingUpdate when setting type to Recreate. The Helm doc does not suggest that this is not possible…

Pain in the ass for me as well 😦

does it work for -f values-file.yaml @rptaylor ?

No, the behaviour for -f and --values is the same.

Here is my summary of some tests I’ve made. Will these cases be treated differently when #11440 or #12162 is merged? Tested with helm 3.11.3. global means the value is under the global i helm values. The number in the key is how deep the key is nested: myKey1, myKey2 etc.

1. First is chart with library dep and explicit -f values.yaml
2. Second is chart with library dep and without explicit -f values.yaml
3. Third is chart without library dep and with explicit -f values.yaml
4. Fourth is chart without library dep and without explicit -f values.yaml

values.yaml

global:
  myKey1: ~
  foo:
    myKey2: ~
    bar:
      myKey3: ~
      baz:
        myKey4: ~

myOtherKey1: ~
foo:
  myOtherKey2: ~
  bar:
    myOtherKey3: ~
    baz:
      myOtherKey4: ~

main.yaml

# global myKey1: {{ hasKey .Values.global "myKey1" }}
# global myKey2: {{ hasKey .Values.global.foo "myKey2" }}
# global myKey3: {{ hasKey .Values.global.foo.bar "myKey3" }}
# global myKey4: {{ hasKey .Values.global.foo.bar.baz "myKey4" }}
# myOtherKey1: {{ hasKey .Values "myOtherKey1" }}
# myOtherKey2: {{ hasKey .Values.foo "myOtherKey2" }}
# myOtherKey3: {{ hasKey .Values.foo.bar "myOtherKey3" }}
# myOtherKey4: {{ hasKey .Values.foo.bar.baz "myOtherKey4" }}

/remove-lifecycle stale

same issue on my side too (also via Argo CD)

Struggling on the same issue with kube-prometheus-stack subcharts

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.