Helmfile: Feature Request: Load helmfiles from a directory

[osterman]

what

• Add support for a --dir option which will process each file as a standalone helmfile.yaml
• Maybe add a --recursive option to scan directories recursively
  e.g.

helmfile --dir conf.d --selector default=true sync

why

• It should be much simpler to iterate over files in a directory than figuring out how to merge multiple templatized YAML files
• Compatibility with CODEOWNERS

use-case

Our helmfile is too big to manage (1330 lines).

additional context

All we're asking is for the equivalent functionality of this:

for conf in conf.d/*; do
  helmfile --file=$conf $@
done

related

• https://github.com/roboll/helmfile/issues/96
• https://github.com/roboll/helmfile/issues/96#issuecomment-379483155

[mumoshu]

@osterman Hi. Thanks for the proposal! I prefer it over helmfile merging yaml files, because it would be straightforward to use.

But I'd rather just add documentation and examples about that use-case if it is just a matter of:

for conf in conf.d/*; do
  helmfile --file=$conf $@
done

So - do you have any specific reason to implement it in helmfile? Perhaps richer error-handling?

[osterman]

@mumoshu it feels like a slippery slope of abstractions. Suppose we call the above "script" helmfiledir.

E.g. we currently do something like this: chamber -> helmfile -> helm -> kubectl

chamber exec backing-services -- helmfile --selector default=true sync

Now we're saying run chamber which will call helmfiledir which will call helmfile which will call helm which will call kubectl.

When will the madness stop!! =)

I look at this propsal as the standard conf.d pattern that is prevalent in many linux apps. Given the nature of what helmfile is trying to solve (complex configurations of helm charts), it seems apt that the functionality belong in the helmfile rather than in yet another wrapper.

references

• http://blog.siphos.be/2013/05/the-linux-d-approach/

[mumoshu]

@osterman Thanks for the response!

Now we're saying run chamber which will call helmfiledir which will call helmfile which will call helm which will call kubectl.

This! I'm going to suffer the almost same thing. Mine adds a bash script that gives AWS and K8S
API access, and kapitan that compiles helmfile.yaml's. Oh my... 😆

What I'm wondering is where helmfile should go. Would it something like "helmfile handles 1 or more helmfile.yaml files well, declaratively, to ease deploying a bunch of helm charts"?

I basically like unix philosophy anyway, and just thinking what this means in the context.

[mumoshu]

@osterman By the way, would you mind if it was implemented without --dir? So, helmfile -f ./ reads the dir and helmfile -rf ./ does it recursively.

kubectl, which we are familiar with, also handles a directory of manifests that way, right?

[osterman]

So, helmfile -f ./ reads the dir and helmfile -rf ./ does it recursively.

Yea, as far as I'm concerned I don't think it matters if we overload the --file argument to handle directories. That said, perhaps renaming --file to --path would be more flexible.

kubectl, which we are familiar with, also handles a directory of manifests that way, right?

Aha, indeed it does, so there would be precedence for doing it this way.

[osterman]

Would it something like "helmfile handles 1 or more helmfile.yaml files well, declaratively, to ease deploying a bunch of helm charts"

Yes, I think we're on the same page. Especially with your analogy to kubectl apply -f some-dir/, that's what we're going for with this feature request.

[osterman]

Also, to incorporate other feedback from @gtaylor:

I think they should be executed lexicographically. To influence the order of execution, one could organize files like this:

helmfiles.d/10.kube2iam.yaml
helmfiles.d/20.chartmuseum.yaml
helmfiles.d/30.externaldns.yaml

references

• https://github.com/roboll/helmfile/issues/96#issuecomment-391082556

[sstarcher]

similar to auto-detecting a helmfile.yaml could we also auto-detect a helmfile.d possibly?

[mumoshu]

@gtaylor @osterman I agree about the lexical ordering

[mumoshu]

Sounds good! Any reason not to include the helmfile.d feature in the first PR for this feature?

[mumoshu]

I have a WIP PR for this at #160. Would you mind taking a look?
It should support helmfile.d.

Do you have any concrete use-case for --recursive now? Can I defer it to another PR?

[osterman]

woohoo! Personally, I don't need a --recursive flag at this point.