Helmfile: Allow opting in for inheriting all the values to sub-helmfile

Created on 19 Jul 2019  路  4Comments  路  Source: roboll/helmfile

Helmfile doesn't inherit values to sub-helmfiles by default today. It does support selectively inheriting some values(#725), but there's no easy way to inherit all the values.

Perhaps it would be nice to add an easy to inherit all the values?

Context: https://github.com/roboll/helmfile/issues/759#issuecomment-512706651

feature request

Most helpful comment

@mikesplain Hey! One possible workaround would be:

helmfiles:
- path: path/to/subhelmfile.yaml
  values:
  - {{ toYaml .Values | nindent 4 }}

And I guess merging just works by adding one array item to to the above:

helmfiles:
- path: path/to/subhelmfile.yaml
  values:
  - {{ toYaml .Values | nindent 4 }}
  - foo: bar

Given the versatility of this workaround, I'm uncertain we really need valuesInherited: true 馃

The use of too much templates has been a maintenance nightmare. But today we have helmfile build which renders the helmfile.yaml template into a plain YAML for auditing, reviewing, and debugging.

All 4 comments

@mumoshu I think this would nice if I am understanding correctly. I have struggled a bit trying to DRY out our existing helmfile in such a way that sane and protective defaults exist in a generic "service" template helmfile which is then included as a sub-helmfile of actual service repo helmfiles in such a way that developers of the service don't have to concern (or accidentally hurt) themselves with generic infrastructure and CI/CD details if that makes sense.

My wish would be to set the environment and values in the sub-helmfile and have those merged with the implementing service helmfile values which are specific to that service.

For example, imagine basic ingress annotations that we want enforced for ALL services, but each service also merges in its own ingress hosts/paths. For our use case it would be nice if all values could be inherited implicitly without having to explicitly add them.

Currently as described by you:

helmfiles:
- path: path/to/subhelmfile.yaml
   values:
   - foo: {{whatever available in the parent}}

Feature flag proposed by you:

valuesInherited: true

It would also be interesting if you could just pass the {{.Values}} root and somehow merge that with the sub-helmfile values root:

helmfiles:
- path: path/to/subhelmfile.yaml
   values:
   - .: {{.Values}}

Yeah I'm pretty surprised this given the way helm it's self's values and subchart values work, which was a bit of a learning curve when starting to use helmfile. I totally understand that there's always reasons, based on the descriptions above. Are there any good work arounds for this?

@mikesplain Hey! One possible workaround would be:

helmfiles:
- path: path/to/subhelmfile.yaml
  values:
  - {{ toYaml .Values | nindent 4 }}

And I guess merging just works by adding one array item to to the above:

helmfiles:
- path: path/to/subhelmfile.yaml
  values:
  - {{ toYaml .Values | nindent 4 }}
  - foo: bar

Given the versatility of this workaround, I'm uncertain we really need valuesInherited: true 馃

The use of too much templates has been a maintenance nightmare. But today we have helmfile build which renders the helmfile.yaml template into a plain YAML for auditing, reviewing, and debugging.

Also cc/ @iAnomaly

Was this page helpful?
0 / 5 - 0 ratings