feat: Ability to define custom template funcs via helmfile.yaml

[mumoshu]

In addition to #244, a kind of aliases or custom template functions to allow writing just {{ myfunc "foo" "bar" }} instead of writing {{ exec "./myfunc" "foo" "bar" }} over and over would be convenient.

How about enhancing the plugin proposal #214 to accept:

templateFuncs:
 myfunc:
   exec: ["./myfunc.sh"]

so that you call just call it like this in your values.yaml template:

{{ myfunc "arg1" "arg2" }}

[elemental-lf]

@mumoshu I'm not sure if uncoupling the definition from the usage, i.e. putting the definition into the helmfile and the usage is in the template, is a good idea. It would hinder template reuse as you'd need to make sure to also copy the definition into the other helmfile which is using the same template. This could also lead to diverging definitions (some might view this as a feature) and confusing behaviour (from a user's viewpoint) if the definition is changed in one helmfile and not the other. I'd leave this for now and maybe reevaluate it in the future. It is as you write more of a convenience than a necessity.

[mumoshu]

@elemental-lf Good point!

Honestly at the time of writing this, I didn't pay much attention about u/x and the temlate reusability. But I do care about them!

My original motivation for this was to make templates DRY.

An alternative way that comes to my mind is to allow importing template helpers like helm does. But it seems challenging in another way, that is how to determine which template helper files to be loaded for the temlate being rendered.

helm does so by looking for templates/_*.tpl. How the convention for helmfile would look like, especially when you have single template helpers file, that is wanted to be used from templates scattered in various levels of directories...

[elemental-lf]

@mumoshu I would shelve this topic for the time being to keep things simple. I mean we just want to render input values for Helm charts and not the charts themselves, right?
If you need a scary example of a template helper file see: https://github.com/openstack/openstack-helm-infra/blob/master/ceph-osd/templates/utils/_osd_daemonset_overrides.tpl. That's the opposite of simple.

[mumoshu]

@elemental-lf Sounds good. Thanks for all the feedbacks!

Your examples does seem very... insightful. After seeing it, I started to more like shelling-out to a more serious command with something like {{ .Environment.Values | toJson | exec "your-own-templater" }}.

Generally speaking, we shouldn't do too much in templates.

[witten]

Here's an example of a common use case in which some sort of parameterizable functions would be useful:

releases:
  - name: myproject
    chart: mycharts/myproject
    values:
      - ../myproject/helm_vars/values.yaml
      - ../myproject/helm_vars/{{ .Environment.Name }}/values.yaml
    secrets:
      - ../myproject/helm_vars/secrets.yaml
      - ../myproject/helm_vars/{{ .Environment.Name }}/secrets.yaml
    labels:
      service: myproject
  - name: otherproject
  ...

I'd need that boilerplate for each and every one of my dozens of releases. What I'd ideally like to do is something akin to this:

releases:
  - {{ template "render-everything-needed-for-a-project-release" "myproject" }}
  - {{ template "render-everything-needed-for-a-project-release" "otherproject" }}
...

And then be able to define that template function, taking the project name as a interpolate-able parameter.

[sstarcher]

@witten I have a similar use case where I have a chart that has about 10 lines of config currently per each of them in helmfile. Where 3 pieces of data are all that will normally differ.

[witten]

This is marked wontfix, but it's also still Open. Is that intentional?

The exec work-around isn't great because it requires taking a dependency on some third-party templating engine. I'm using Helmfile at least in part because of it's templating ability! So ideally I'd just like a way to DRY up all the repetition in my Helmfiles via built-in templating. (See example above.)

In regards to Helm's comparable feature and templates/_*.tpl, you could sidestep the "where to look for templates" problem by just requiring them to be defined in the same file as where they're consumed, at least to start with. And then if that becomes a problem later on, you could layer on include or template file probing support like what Helm has. But that wouldn't be needed out of the gate for very basic template function support.

[mumoshu]

We already have an issue for tracking the potential addition of {{ include }} #1345.
Closing.