Deleting a default key in a subchart

[kovayur]

Bug Report

Hi,

I have a situation when I need to delete a default key from a dependent subchart in my main chart by setting it to null as described here. In other words, set the value in the root values.yaml to null to override the default value in the subchart I'm loading as a dependency.

More specifically, this configuration is required to install the External Secrets Operator (sub)chart on OpenShift: external-secrets/external-secrets#2342

It works with helm upgrade but doesn't work if I bundle the chart inside an operator.
I tried to set the null values in the CR but it didn't work either. I also tried to set value overrides in watches.yaml, but in my case it failed with a string type conversion error.

There was a bug in helm that prevented this behavior, but it has been fixed in recent versions (I'm using 3.13.2). Perhaps, a helm version bump could solve the problem.

What did you do?

Set the value in the root values.yaml to null to override the default value in the subchart I'm loading as a dependency.

What did you expect to see?

The default value is deleted

What did you see instead? Under which circumstances?

The default value of the subchart is present

Environment

Operator type:

/language helm

Kubernetes cluster type:

OpenShift

$ operator-sdk version
v1.32.0

Possible Solution

Bump helm version

[varshaprasad96]

@kovayur Are you able to pull the dependent helm chart into the operator project? In the sense, is it available locally inside the charts/ folder of your project?

We have seen some issues in the past, where users were not able to fetch the dependencies after running the init command. Hence, just wanted to check this step first to see the setup of dependencies is successful?

[kovayur]

Hi @varshaprasad96 ,

Yes, I pull the dependencies during the docker build.
So far, I've been able to work around the problem by manually unpacking the dependency and removing the keys from the subchart in the Dockerfile:

cd charts && for filename in *.tgz; do tar -xf "$filename" && rm -f "$filename"; done && \
    yq -i 'del(.securityContext.runAsUser) | del(.webhook.securityContext.runAsUser) | del(.certController.securityContext.runAsUser)' external-secrets/values.yaml

[varshaprasad96]

@kovayur Could you specify the helm version which fixes this particular issue? Operator SDK 1.32 uses an older version of helm (3.11.3:

operator-sdk/go.mod

Line 36 in 4dcbbe3

helm.sh/helm/v3 v3.11.3

). It would be helpful to know if this version has this issue fixed in the helm upgrade command.

[kovayur]

@varshaprasad96 According to the release notes this is fixed in version 3.13.1.

Values handling had numerous issues fixed and now consistently has a priority of (1) User specified values (e.g CLI), (2) parent chart values, (3) imported values, and (4) subchart values. Additionally, null can now consistently be used to remove values. Note, there is a regression around this in 3.13.0 that's fixed in 3.13.1.

I tested it on 3.13.2.

[varshaprasad96]

Looks like the version of helm we are using is still 3.12.1:

operator-sdk/go.mod

Line 36 in 8721645

helm.sh/helm/v3 v3.12.1

We should be bumping to 3.13+ with a k8s 1.28 update which is underway. Hopefully that would fix the issue.

Meanwhile, could you please try bumping the helm version alone to 3.13+ and build the helm image locally to test? There have not been many breaking changes on the k8s client between the 2 minor k8s versions. Keeping the other deps same (especially controller-runtime), and trying to build the binary with updated helm could help verify if this needs just the helm update.

[acornett21]

/assign

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kovayur]

/remove-lifecycle stale

[kovayur]

I see that the helm version has already been updated. I'll try to re-test on the latest version.