Skip to content
This repository has been archived by the owner on Aug 22, 2022. It is now read-only.

Add option to allow usage of Helm Templates in all values of values.yaml file items #131

Open
MurzNN opened this issue Feb 18, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@MurzNN
Copy link
Contributor

MurzNN commented Feb 18, 2022

Details

Helm chart name: common

Describe the solution you'd like:

By default template variables like {{ .Release.Name }} and {{ .Chart.Name }} are not working in values.yaml files (here is some issues about this: helm/helm#3558, helm/helm#2492), and that's sad...

But seems we can get rid of this limitation via implementing parser of each value in common library!

Here is an example of adding support for template conversion in value from values.yaml file of manually defined key persistence.config.existingClaim, described in templates/common.yaml:

{{- include "common.values.setup" . }}

{{-
$_ := set .Values.persistence.public
  "existingClaim"
  (print (tpl .Values.persistence.public.existingClaim .))
-}}

{{ include "common.all" . }}

Having this, we can use templates inside value of that key directly in values.yaml file, like this:

persistence:
  public:
    enabled: true
    type: pvc
    existingClaim: "{{ .Release.Name }}-{{ .Chart.Name }}-my-config"

And via same way we can loop through each of the keys in passed values.yaml file and make the template conversion for each value (or only defined ones)!

So we can add this as opt-in feature that should be enabled via some key, for example like this - global switcher for all values:

parseTemplatesInValues: true

and only for selected values:

parseTemplatesInValues: 
  - envFrom[0].secretRef.name
  - persistence.config.existingClaim

What do you think about this idea?

@MurzNN MurzNN added the enhancement New feature or request label Feb 18, 2022
@bjw-s
Copy link
Contributor

bjw-s commented Feb 18, 2022

We already do this for some of our values, for example in the env section. I've been toying with the idea to implementing it in more places but haven't thought through how to best do it.

The main thing we should try to prevent (as always) is jumping the shark with templating. We don't want or need our library to be a generic templating language for a generic templating language for ... etc.

@MurzNN
Copy link
Contributor Author

MurzNN commented Feb 19, 2022

Thanks for detailed explanation, yes - yet another templating language will be overkill ;-)
So maybe we can invent some helper function, that simplifies such conversion via single simple line in common.yaml?
Something like:

{{ parseTemplatesInValues envFrom[0].secretRef.name . }}
{{ parseTemplatesInValues persistence.config.existingClaim . }}
{{ include "common.all" . }}

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants