Helmfile: Propagate helmDefaults to `helmfiles`

[RobertoUa]

Suppose I have a helmfile.yaml with helmDefaults and helmfiles with a list of files. How do I propagate values from helmDefaults to these child helmfiles?

I know if I'd used releases instead of helmfiles it would've worked. But I have some CRDs and putting everything in releases wouldn't work. Using helmfiles only for CRDs and releases for everything else also wouldn't work for me.

helmfile.yaml

helmDefaults:
  tillerNamespace: kube-system
  tillerless: true
  kubeContext: context
  verify: true 
  wait: true
  timeout: 600

helmfiles: #helmDefaults are not propagated to these files
  - dashboard-values.yaml
  - metrics.yaml
  - prometheus.yaml
  - consul-values.yaml
  - redis-values.yaml

[mumoshu]

@RobertoUa Hey! Unfortunately it isn't impossible.

Alternatively, I'd suggest you to use values overrides when calling sub-helmfiles.

That is, in your parent helmfile.yaml you override helmfile state values like:

helmfiles:
- path: dashboard-values.yaml
  values:
  - helmDefaults:
      tillerless: true
      wait: true
      # snip
````

And then in your sub-helmfiles you render the helmDefaults from state values:

values:

• helmDefaults:
  tillerless: false
  # snip

helmDefaults:
{{ .Values.helmDefaults | toYaml }}

releases:
...
```

Helmfile state values (values:) is considered (almost) only the parameters passed to helmfile. So this method can be also good as it is clear to the user of subhelmfiles that those subhelmfiles supports overriding helmDefaults from the caller-side.

[RobertoUa]

Thank you!

But how do I do it in a DRY way? Can I store helmDefaults in a separate file and somehow load it in every helmfile (parent & children)?

[mumoshu]

Yeah try this:

common.yaml:

helmDefaults:
  tillerless: true

helmfile.yaml

helmfiles:
- path: dashboard-values.yaml
  values:
  - 
{{ readFile "common.yaml" | indent 4 }}

[RobertoUa]

that's great! It seems that I can just add {{ readFile "common.yaml" }} to every helmfile and that's it!

Can I ask what is the motivation for not propagating values to child helmfiles?

[RobertoUa]

What would be really great if I could just use releases instead of helmfiles. But it would require a flag which would make some dependencies load as if they were loaded from helmfiles, because they have CRDs and the following dependencies will fail otherwise. Does it make sense?

UPD: seems that https://github.com/roboll/helmfile/issues/715 will solve the issue! When can I expect this feature to be released? :)

[mumoshu]

Yep #715 would help that.

Sorry, I can't promise anything as I'm maintaining this in my spare time :) But generally speaking, the more interest an issue gets, the more likely it is prioritized higher than others.

[mumoshu]

Can I ask what is the motivation for not propagating values to child helmfiles?

To balance safety, reusability and maintainability. Making everything easily overridable from the caller-side seemed to make user support a nightmare from a perspective of the sub-helmfile author.

In other words, I believe the best-practice is to author each sub-helmfile expose only supported options via helmfile (enviroment) values. If it's an overkill for you, maybe you don't need sub-helmfiles. You rather need #715, as you just reliazed.

[RobertoUa]

each sub-helmfile expose only supported options via helmfile (enviroment) values

does that mean that enviromnent gets propagated?

(I wish docs could clearly say what gets propaged where)

[mumoshu]

Nothing is implicitly propagated from the parent to the sub helmfile. You need to be explicit like https://github.com/roboll/helmfile/issues/867#issuecomment-533320215

[RobertoUa]

thanks a lot for your help! I'm closing this issue and waiting for #715 :)