Helm-operator: 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.

[alanjcastonguay]

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