Debug helmrelease before committing to GitOps

[michaelfig]

Feature request: Add a command to fluxctl that can debug a helmrelease yaml without first having to apply it to the cluster and ensure all the chart references are pushed.

Say I have a myrelease.yaml file:

---
apiVersion: flux.weave.works/v1beta1
kind: HelmRelease
metadata:
  name: my-release
  namespace: dev
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.chart-image: glob:master-*
spec:
  releaseName: my-release-name
  chart:
    git: somewhere:/foo/bar.git
    ref: master
    path: charts/myserver
  values:
    image:
      repository: my-image-repo/my-imagebamappserver
      tag: foobar
    replicaCount: 2
    ingress:
      enabled: true
[...]

I'd like something like fluxctl helm-template ./myrelease.yaml /path/to/my/chart to run the moral equivalent of:

helm template --values=- --namespace=dev --name=my-release-name /path/to/my/chart

where the stdin (used by the --values=- switch), is generated like:

image:
  repository: my-image-repo/my-image
  tag: foobar
replicaCount: 2
ingress:
  enabled: true
[...]

This would make debugging flux helmreleases a lot more pleasant!

If you are willing to take a PR to implement this (or a modified proposal), let me know, and I can try to cook one up.

Thanks,
Michael.

[squaremo]

I like this idea -- it'd give people a extra degree of confidence when moving to HelmReleases, as well as being generally helpful.

To get as close as possible to what the helm-operator will do, I think the tool would have to

• clone the git repo to get the chart, if it has a git source
• or, fetch the chart tarball
• look up any value secrets/configmaps/URLs
• dry-run the chart

There's code for all of these things individually in integrations/helm, though it's not necessarily straight-forward to repurpose it.

I think we can consider these as assumptions:

• the user has access to any git repo in question
• the user can read any secrets, configmaps, and URLs mentioned in the HelmRelease
• similarly charts and their dependencies (i.e., the tool does not have to try and get the repositories.yaml from the operator)

I'm not sure where it would live -- fluxctl is so far ignorant of Helm -- but let's leave such doctrinal questions for later.

[michaelfig]

I would like to at least be able to provide an override for the chart location, as in my org I only can update the master chart repository with a PR to the operations team, and I would like to test the chart locally before doing that. In some environments, I don't have access to the git repo containing the production charts, either.

Also, I don't always want to dry-run the chart. Sometimes I want to inspect the output directly. I'd like to provide an interface very similar to what helm template is (and all its flags), which I already use extensively while developing the chart before I have a helmrelease.yaml.

[ellieayla]

An alternative approach here, maybe more composition-friendly.

I wanted something that consumes yaml defining a HelmRelease object and spits out the content of spec.values, so I can do something with it. Probably just pass to helm template --values and then to kubeval. Supposedly this can be done with yq, but I didn't have that at-hand.

I ended up trying something like (untested jsonpath, memory):

kubectl apply -f stuff/ --dry-run -o=jsonpath='{range .items[?(.kind=="HelmRelease")]}{.spec.}{"\n"}{end}'

[hiddeco]

Small wrapper that makes use of yq to collect the values and release name: https://gist.github.com/tun0/845e796008ac6ca6229af910682c6983

[kingdonb]

Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller.

A new release of Helm Operator is out this week, 1.4.4.

We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository.

Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2.

In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo.

Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved.

We recommend upgrading to Flux v2 which is actively maintained ASAP.

I am going to go ahead and close every issue at once today,
Thanks for participating in Helm Operator and Flux! 💚 💙