Specify arbitrary helm values on KOTS CLI

As a vendor, I have >800 helm values in my main chart, and I surface only a few in my Kots HelmChart and Config resources. Sometimes for CI or expert use, we use some hidden Config options to pass through a few values to the helm install, and use --config-values to poke them. But this needs you to have wired that option in advance.

Is there a better way to pass through ad-hoc values like helm install --set or --values?

A few revs ago, Kots removed the --set option; maybe it was broken. But a clean implementation would let you specify which HelmChart spec.chart.name you want to override and then let you pass a values.yaml which might be passed down to helm install as another --values, if that makes sense? Attempting --set would probably be less flexible. Roughly

--helm-values BigCorpChart=myvalues.yaml

Thanks for reading

Hi @Mitch,

Yes, there is somewhat a better way to achieve this. Let me try to explain and let me know if anything is unclear.

You can basically define a generic config item that accepts arbitrary YAML to be merged with the existing Helm values and passed down to the Helm chart.

Here’s an example:

In your KOTS config, add the following two config items:

        - name: enable_custom_helm_overrides
          title: Enable Custom Helm Overrides
          help_text: Enable Custom Helm Overrides
          type: bool 
          default: "0"
        - name: custom_helm_overrides
          title: Custom Helm Value Overrides
          type: textarea
          default: ""
          when: "repl{{ ConfigOptionEquals `enable_custom_helm_overrides` `1`}}"

Then, in the HelmChart custom resource, add the following as the last entry in the optionalValues field:

  optionalValues:
    # ... other/previous entries go here (if any) ... #
    - when: "repl{{ ConfigOptionEquals `enable_custom_helm_overrides` `1`}}"
      recursiveMerge: true
      values: repl{{if ConfigOptionEquals "custom_helm_overrides" ""}}{}repl{{ else }}repl{{ ConfigOption "custom_helm_overrides" | nindent 8 }}repl{{ end }}

Make sure to include the recursiveMerge: true from the snippet above as to not override top-level sub-fields.

With that, you have a KOTS configuration item that accepts arbitrary Helm values to be passed down to the Helm chart, and those values are recursively merged with the other values.

When using the KOTS CLI to install, those values would have to be included in the config values file that is passed to the install command, and cannot be provided separately. But, you can for example have a go/bash script that merges those Helm values from another file into the config values files before running the KOTS install command.

Hope that helps!

Hi @salahalsaleh -

Yes this makes total sense and is exactly what we need, thank you!

2 Likes

Just a followup for the next person. I think you must be running at least KOTS 1.105.2 to do this due to fix: use rendered KOTS kinds to create version even when configuration is needed by sgalsaleh · Pull Request #4332 · replicatedhq/kots · GitHub which is fixed in that version.

Earlier version might give this message, included for searchers:

Error: failed to validate installation: failed to create online app: failed to pull: failed to load kotskinds: failed to walk upstream dir: failed to add kots kinds from /tmp/kots2430940271/upstream/mychart.yaml: failed to decode yaml content: json: cannot unmarshal string into Go struct field OptionalValue.spec.optionalValues.values of type map[string]v1beta2.MappedChartValue