Values.yml file for HelmRelease with HelmRepo src

[pdeva]

I have a HelmRelease which refers to a HelmChart in a HelmRepo. I need to pass it a fairly long (~800 lines long Values.yaml file).

The documentation here says to use a ConfigMap to store helm chart values. As for using a Values.yaml file, the best description I could find is this line:

valuesKey (Optional): The data key where the values.yaml or a specific value can be found. Defaults to values.yaml when omitted.

This is a little confusing.

1. Does this mean i need to have a 'key' called values.yaml in my ConfigMap that contains the actual contents of my 'Values.yaml' file as a string? Wont that be very error prone for large Values.yaml file (> 500 lines long)?

2. Is there no way to refer to an actual Values.yaml file ?

[hiddeco]

You have two options to configure it on the HelmRelease:

1. Put it in .spec.values of the HelmRelease, which supports structured YAML.
2. Put it in a ConfigMap or Secret:

   apiVersion: v1
   kind: Secret
   metadata:
     name: release-values
   stringData:
     values.yaml: |
       nested:
         values: here

There is no way to refer to an actual values.yaml file, because the controller can only look at Kubernetes API objects (like a ConfigMap, Secret and the HelmRelease itself), and has no means to retrieve any file reference unless it is included with the chart. In which case you can configure it on the HelmChart, see .spec.valuesFiles for more information on this.

Note that you only need to include values which differ from the chart defaults, as they are merged on top (like helm install --set, helm install -f, etc.).

[pdeva]

hi @hiddeco. thanks for the reply. here are my notes to your points:

1. the .spec.values field only works for file paths relative to the chart location. Take for example installing the datadog-agent helm chart from the datadog helm repo. In this case the helm repo and chart is not under our control. So we cannot use the .spec.values field in this case to pass our values.yaml file.

2. I understand this is indeed the only solution, however this has the following 2 disadvantages:

a. the 'value' of values.yaml key in the ConfigMap is stored as a string. This means all editors like Intellij, etc will highlight it as a single string value making it tough to use any intelligent editor features. Not to mention, we have to mess with the indentation of the original values.yaml file to add the indentation of the 'values.yaml' key. While none of this would be an issue for a small set of values, for a large, complex helm chart like the datadog-agent, the values.yaml can be hundreds of lines long, making editing it very tedious and error prone in an editor as a 'value' of a key in a yaml file.

b. its unclear from the docs whether the changes in this ConfigMap will be picked up by Flux...

Possible solution

I wonder why Flux doesnt allow pointing .spec.values to a file external from the Chart source. Flux already checks for changes in our git repo, why cant we point it to a values.yaml file in our git repo which it can just watch for changes.

[hiddeco]

I wonder why Flux doesnt allow pointing .spec.values to a file external from the Chart source. Flux already checks for changes in our git repo, why cant we point it to a values.yaml file in our git repo which it can just watch for changes.

This seems to be an oversimplification of what Flux (today) does. Flux has several microservices (controllers) that all together control the lifecycle of your Helm release, including (potentially) watching a Git repository and applying changes observed there to the cluster. Using Kubernetes Custom Resource Objects as an abstraction layer.

Effectively, this means that the helm-controller only works with packaged Helm charts made available by the source-controller. It does not have direct access to the Git repository, but rather looks at the result produced by a HelmChart object (which can package a chart from a GitRepository).

The HelmRelease and other objects are applied to the cluster by the kustomize-controller, allowing you to make use of Kustomize features for any requirements you have around the construction of Secret or ConfigMap objects, like generators. See also our documentation about managing these object types using this.

Altogether, I think there should not be a need for what you are requesting. Because you should be able to provide the values in several other ways, native to the solutions we build upon.

its unclear from the docs whether the changes in this ConfigMap will be picked up by Flux...

They are re-observed every .spec.interval, in which case a change of the ConfigMap (or apply if the name of the reference changes in the HelmRelease) will trigger an upgrade. If you want this to be detected faster, you can make use of a generator as I referred to above. See link to doc.

the .spec.values field only works for file paths relative to the chart location. Take for example installing the datadog-agent helm chart from the datadog helm repo. In this case the helm repo and chart is not under our control. So we cannot use the .spec.values field in this case to pass our values.yaml file

The .spec.values field takes any arbitrary YAML object as input, you can thus declare any values.yaml file there in a structured way. I do not see how this relates to any chart location and/or path reference. Can you elaborate?

[pdeva]

hi @hiddeco.

The .spec.values field takes any arbitrary YAML object as input, you can thus declare any values.yaml file there in a structured way.

my apologies. i mixed up .spec.values with .spec.valuesFiles in my answer. Its .spec.valuesFiles that needs the values.yaml to be relative to chart source, as mentioned inteh doc here:

The file paths are expected to be relative to the Source reference.

If it allowed pointing to an external source like a git repo it is watching, then we could just place the values.yaml file separately and refer to it.

[eguarc]

hi @hiddeco and @pdeva
I would like to introduce our simple case.
Following this article: https://fluxcd.io/flux/guides/repository-structure/ we are working in a Repo per app way. Developers can modify some values inside app repo and we (kind of operations team) manage the config repo.
Inside config repo we generate a HelmRelease that points to a HelmRepository. What if developers want to change some value? In case of working with GitRepository and HelmRelease there is no problem (while storing templates inside app repo), but what if someone would like to work with some official or packaged charts as bitnami? Do we have to deal with generators or trigger an action from repository platform?

I've read https://fluxcd.io/flux/migration/helm-operator-migration/#values-from-external-source-references-urls-are-no-longer-supported and there is something I can't understand:

You can not reliably restore the cluster state from a Git repository if the configuration of a service relies on some URL being available.

I understood about calling external repos but on the other hand I can create an object to retrive templates AND values from the same platform where fluxcd was installed.

I know maybe sounds lisergic but there would be great something like:

valuesFiles:
  sourceRef:
    kind: GitRepository
    name: play
    file:  .helm/app/values.yaml

[alee2233]

I followed the guidance here and it seems to works pretty well: https://fluxcd.io/flux/guides/helmreleases/#refer-to-values-in-configmaps-generated-with-kustomize

[tculp]

I agree with #2919 (reply in thread) and I think that valuesFrom should absolutely be able to pull from a GitRepository. Our use case is having separate folders for the infra for different deployments, and we would like the values files to live in those folders rather than in the chart at the top level.

Example:

- chart/
- dev/
  - infra/
  - values.yaml
- stage/
  - infra/
  - values.yaml

Unfortunately to make a configmap and keep it synced to the cluster, we would need to add an extra kustomization.yaml and Kustomization resource to use it, which just feels like unneeded overhead.

Pulling from a Source kind like a GitRepo seems like it would fit in perfectly with the rest of the Flux and GitOps paradigms, and before I looked into it I naturally assumed that

valuesFrom:
  - kind: GitRepo
    name: foo
    path: bar

would be supported.

[djds]

Here's what I do:

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- helmrelease.yaml
- helmrepository.yaml
configMapGenerator:
- name: foo-helm-values
  namespace: foo
  files:
  - values.yaml
  options:
    # not apparently supported by the flux HelmRelease
    disableNameSuffixHash: true
    immutable: false
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: foo
  namespace: foo
spec:
  interval: 10m
  timeout: 5m
  chart:
    spec:
      chart: foo
      version: "1.3.3.7"
      sourceRef:
        kind: HelmRepository
        name: foo
      interval: 5m
  releaseName: foo
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
  test:
    enable: true
  driftDetection:
    mode: enabled
    ignore: []
  valuesFrom:
  - kind: ConfigMap
    name: foo-helm-values
    valuesKey: values.yaml

[stefanprodan]

@pdeva in your case, if both the values.yaml and HelmRelease are in the same repo, you can use the hash suffix. You just need to add a Kustomize config to your kustomization.yaml, docs here: https://fluxcd.io/flux/guides/helmreleases/#refer-to-values-in-configmaps-generated-with-kustomize