Kustomize helmCharts valuesInline doesn't replace default valuesFile

[thoraage]

What happened?

With kustomization:

...
helmGlobals:
  chartHome: ../../../helm-charts

helmCharts:
  - name: da-vault-secret-store
    namespace: vault
    releaseName: da-vault-secret-store
    valuesInline:
      myvalue: "myvalue"
...

I get:

$ kustomize build --enable-helm infrastructure/vault/test
Error: security; file 'xxxxxxxxxxxxxxxxxxx/da-vault-secret-store/values.yaml' is not in or below 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/infrastructure/vault/test'

It seems I would have to make an empty dummy-values-file to point the valuesFile-key or turn of load restrictions to make it work. That seems very inelegant.

I tried to remove the values.yaml-file from the helm-chart, but that did not solve anything:

$ kustomize build --enable-helm infrastructure/vault/test
Error: evalsymlink failure on 'xxxxxxxxxxxxx/helm-charts/da-vault-secret-store/values.yaml' : lstat xxxxxxxxxxxxxxx/helm-charts/da-vault-secret-store/values.yaml: no such file or directory

Also it would have been great if this could work without valuesFile or valuesInline. For example, if the helm-chart didn't depend on any values other than for example namespace (i.e. .Release.Namespace).

What did you expect to happen?

I expected it to only use values from my valuesInline-key.

How can we reproduce it (as minimally and precisely as possible)?

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- resources.yaml

# resources.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-object
data:
  placeholder: data

Expected output

Actual output

Kustomize version

v5.0.1

Operating system

None

[annasong20]

Hi @thoraage, you are probably looking for the replace value for the valuesMerge field. This value tells kustomize to completely replace the default values.yaml included with the downloaded chart with your valuesInline value, and so unlike with the other valuesMerge values, kustomize does not bother to read the default values.yaml.

You are right that deleting the values.yaml file doesn't help. Kustomize will try to read the default values.yaml unless you use replace or specify your own values.yaml.

Regarding your 2nd point,

Also it would have been great if this could work without valuesFile or valuesInline. For example, if the helm-chart didn't depend on any values other than for example namespace (i.e. .Release.Namespace).

you are correct that currently to specify an empty values.yaml, you have to create an empty file and point valuesFile to it. Kustomize will ignore an empty valuesInline.

However, I don't believe this is an issue? If you don't want to create an empty file and leave both the valuesFile, valuesInline fields empty, kustomize will load the default values.yaml that comes with the helm chart. Given your use case, the default values.yaml should already be empty because there aren't any non-"builtin" ("builtin" being variables like .Release.Namespace) variables in the chart. Thus, the result of running helm should be the same as if you specified neither valuesFile nor valuesInline? I have a limited understanding of helm, so please correct me if I'm wrong.

P.S. Sorry, I don't understand how your example yaml files relate to the rest of your issue. Please elaborate if relevant.

/kind support
/triage needs-information

[thoraage]

Thank you for the information about valuesMerge, I didn't know about that one.

There is still an issue with empty valuesInline and valuesFile. I don't keep my helm-charts in the same directory as the kustomization.yaml-file. Instead I keep them in a separate directory and include them like this:

helmGlobals:
  chartHome: ../../../helm-charts

That leads me to getting the error below:

$ kustomize build --enable-helm infrastructure/vault/test
Error: security; file 'xxxxxxxxxxxxxxxxxxx/da-vault-secret-store/values.yaml' is not in or below 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/infrastructure/vault/test'

To avoid this I'll have to used the arguments which I really do not want to apply: --load-restrictor LoadRestrictionsNone

[itewk]

i just ran into this same problem :(

[zMynxx]

Thank you for the information about valuesMerge, I didn't know about that one.

There is still an issue with empty valuesInline and valuesFile. I don't keep my helm-charts in the same directory as the kustomization.yaml-file. Instead I keep them in a separate directory and include them like this:

helmGlobals:
  chartHome: ../../../helm-charts

That leads me to getting the error below:

$ kustomize build --enable-helm infrastructure/vault/test
Error: security; file 'xxxxxxxxxxxxxxxxxxx/da-vault-secret-store/values.yaml' is not in or below 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/infrastructure/vault/test'

To avoid this I'll have to used the arguments which I really do not want to apply: --load-restrictor LoadRestrictionsNone

Using this flags does do the trick, or hard linking the values file.
Any changes in the last 6 months regarding this issue?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[itewk]

This is still an issue last I checked.

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale