Output values.yaml for HelmRelease Resources

[drewmarshburn]

I have a question related to #453: is there an easy way to see the final values.yaml used by a HelmRelease resource?

Our HelmRelease resources are pretty complicated; we rely heavily on the ordered values merging of spec.valuesFrom from several Secret and ConfigMap resources in addition to spec.values. When the Helm installations succeed, I can use something like helm get values CHART -n NAMESPACE to see what is effectively the values.yaml file. However, when the Helm installations fail, I am stuck trying to piece together a pretty complicated hierarchy of valuesFrom and values references to debug my Helm installations. Is there an easy way to see this that I have somehow missed? Thank you!

[drewmarshburn]

I am still having trouble debugging failed HelmRelease reconciliations and haven't found a workaround yet. Any thoughts?

[stefanprodan]

You can tell Flux to leave the Helm release in place when it fails with disableWait, so you can get the values with Helm CLI. Docs here: https://fluxcd.io/docs/cheatsheets/troubleshooting/#how-to-debug-install-retries-exhausted-errors

[drewmarshburn]

Thanks for getting back to me! I've just tried to use disableWait for install and upgrade, but my issue is actually that the Helm installation fails outright. Thus, I'm not sure that these flags will help me?

To be more specific, I am getting this error:

Helm install failed: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Deployment.spec.template.spec.containers[0].volumeMounts): invalid type  ││ for io.k8s.api.core.v1.Container.volumeMounts: got "string", expected "array", ValidationError(Deployment.spec.template.spec.volumes): invalid type for io.k8s.api.core.v1.PodSpec.volumes: got "string", expected "array"]

I have used helm template --debug --dry-run locally with what I believe is the correct set of values that Flux will assemble and it produces valid Deployments. Would there be a way for me to see the output of helm template or something similar, or even just to see the final values.yaml file that Flux is using to perform the installation?

[stefanprodan]

Currently there is no way to get the values.yaml from the controller, given the values can contain secrets I don't see how we could expose it in a safe way. cc @hiddeco

[drewmarshburn]

I do see that, for successful chart installations we've made with HelmRelease resources, helm get values can return secret values that we referenced within valuesFrom. If I understand it correctly, helm get is getting that release data from Secret resources that correspond to the installations, perhaps we could consider a similar approach?

Another thought that comes to mind is a suggestion implied here: #453 (comment). Would there possibly be a way to run helm template via the Flux CLI and see the output, assuming we could run helm template using the fully assembled set of values from Flux?

[stefanprodan]

Would there possibly be a way to run helm template via the Flux CLI and see the output, assuming we could run helm template using the fully assembled set of values from Flux?

If you use valuesFrom with a secret how would the CLI find the secret on disk?

[drewmarshburn]

If you use valuesFrom with a secret how would the CLI find the secret on disk?

I do see that the CLI is capable of creating Secrets via the k8s client, though I understand that reading application-layer secrets used in HelmReleases is a very broad and different permission.

To bring the discussion back up a level, I don't really have a proposal for how to accomplish what I've described, but there are two things that would be really helpful to me if either is possible:

• Running helm template via the Flux CLI to debug HelmRelease resources using the values Flux is gathering from valuesFrom references. (Or otherwise somehow having a template option available in HelmRelease resources that could generate helm template output, perhaps into a Secret.)
• Seeing the final values.yaml that Flux assembles from valuesFrom references and uses as the input to a helm installation.

I would be interested in making a contribution but would need some guidance on whether either of these are possible (or should be possible in case these present significant security concerns) and how they might best be achieved.

Thanks for your time!

[drewmarshburn]

Any thoughts on this thread? Thanks!

[Zalastax]

The previous Helm Operator had a similar feature request with many upvotes: fluxcd/helm-operator#15

If RBAC is the issue, are any of these options feasible?

• Inherit RBAC from the CLI user. The CLI will only print the data if the user can read the Secret.
• Print the data to a new Secret. The user can only read the data if they have access to Secrets. Copies data between Secrets though, so not perfect from RBAC perspective

[Zalastax]

Thanks @nightswimmings, could you possibly expand on your thoughts just a little bit? I am not sure how your advice would enable debugging valuesFrom. I understand your advice as instead being an alternative workflow which can help produce the input to provide to a HelmRelease?

[nightswimmings]

Right, I was in the same trouble and I got 2 tickets mixed, this is the wrong one

[SebSa]

This would be useful to debug this issue im facing:
#713

[amit-disc]

@stefanprodan @drewmarshburn Also wanted to understand that running helm cli command(template) will result in the exact same output as helm-controller? Does helm-controller use the same APIs? or is there a difference between helm-controller and helm cli tool?

[stefanprodan]

@amit-disc Flux uses the same Helm SDK as the Helm CLI, there no differences in terms of resulting manifests.

[nourspace]

The merging of valuesFrom is missing though. The final values can be only debugged using the controller. Making diffs pretty tricky if using multiple config files.

[stefanprodan]

The merging of valuesFrom is missing though.

The merge that Flux performs is identical to what the CLI does when you pass multiple values files.
You can query the cluster for the valuesFrom objects and extract the values locally with yq then pass them to helm template --values=val1.yaml --values=val2.yaml.