helm-controller
helm-controller copied to clipboard
Output values.yaml for HelmRelease Resources
I have a question related to https://github.com/fluxcd/helm-controller/issues/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!
I am still having trouble debugging failed HelmRelease
reconciliations and haven't found a workaround yet. Any thoughts?
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
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?
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
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: https://github.com/fluxcd/helm-controller/issues/453#issuecomment-1100125577. 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?
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?
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 debugHelmRelease
resources using the values Flux is gathering fromvaluesFrom
references. (Or otherwise somehow having atemplate
option available in HelmRelease resources that could generatehelm template
output, perhaps into aSecret
.) - Seeing the final
values.yaml
that Flux assembles fromvaluesFrom
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!
Any thoughts on this thread? Thanks!
The previous Helm Operator had a similar feature request with many upvotes: https://github.com/fluxcd/helm-operator/issues/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
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?
Right, I was in the same trouble and I got 2 tickets mixed, this is the wrong one
This would be useful to debug this issue im facing: https://github.com/fluxcd/helm-controller/issues/713
@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?
@amit-disc Flux uses the same Helm SDK as the Helm CLI, there no differences in terms of resulting manifests.
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.
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
.