Open kovayur opened 8 months ago
@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?
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
@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: https://github.com/operator-framework/operator-sdk/blob/4dcbbe343b29d325fd8a14cc60366335298b40a3/go.mod#L36). It would be helpful to know if this version has this issue fixed in the helm upgrade command.
@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.
Looks like the version of helm we are using is still 3.12.1: https://github.com/operator-framework/operator-sdk/blob/872164516b44c0586407097da089241c9d8d6b75/go.mod#L36
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.
/assign
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
/remove-lifecycle stale
I see that the helm version has already been updated. I'll try to re-test on the latest version.
Can't test on 1.34.[0-2] because of the reconcilation issue https://github.com/operator-framework/operator-sdk/issues/6690
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 rootvalues.yaml
tonull
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: https://github.com/external-secrets/external-secrets/issues/2342
It works with
helm upgrade
but doesn't work if I bundle the chart inside an operator. I tried to set thenull
values in the CR but it didn't work either. I also tried to set value overrides inwatches.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
tonull
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.0Possible Solution
Bump helm version