-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add include'able sub-helmfiles #96
Comments
There's a similar discussion with more use-cases happening on #59 |
Thanks for the tip. Though, I think we'd be more interested in splitting up the actual releases as opposed to defining default values (as per #59). |
@gtaylor Thoughts on instead of doing an include being able to glob the files files in the folder
or maybe loading all helmfiles in a directory The complexity of the overriding and collisions concerns me. Instead of allowing things to be override I would prefer they collide and error out. You might be able to handle your overriding between environments if my proposal here is taken into account #59 (comment) and this PR #98 |
Since we'd like the ordering to be significant (to allow for the similar-but-separate cluster overrides), that makes a globbing approach clumsy to deal with. What collisions are we talking about? We have release names to key off of. If a release has been seen before, we blow the existing struct away and replace it with the most recently seen. That can be managed with something like a |
ya, exactly I find out odd to blow away a previous structure for collisions. Why do you want ordering to be significant? I think it's a misnomer to want to consider releases to be significant or do you mean the merging of includes? I think the merging could be better handled by values files that are loaded per environment. With your example why would you ever want team b to be able to override the release from team a? |
Also, to add a use-case, we're creating a distribution of helm charts that install out-of-the-box on kops. Our |
I'm going to suggest something possibly terrible today! How about adding dependencies:
- prod/org.yaml
- prod/team.yaml
- _helpers.tpl
But I'd recommend not to do too much in
The source of inspiration for this is helm's named templates and chart dependencies. So, hopefully this makes sense to helm users, while supporting all the use-cases gathered until now... WDYT? |
Also see #59 for default values templating. |
The implementation should be simple. Probably it is a matter of some extra file loading through But beware, the requested I also suggest jsonnet or else if you get to find the life in this helm'ish way of reusability too hard. If you go that way, you can just remove almost all the |
That would be great! Though, I'm not sure we should use the word "dependency", since that has existing (and different) meaning in Helm. |
I'm still interested in the ability to load values that can be used for interpolation as I view that as alot more powerful than merging yamls together. Especially for complex charts that don't follow the normal hierarchy. |
@sstarcher I guess you're talking about an alternative to envvars referenced via |
ya, I believe that would solve the issues with reusable data more cleanly then merging values files together as they are limited in structure. |
@gtaylor Good point! I originally took it inspired by helm's requirements.yaml thinking it would be easier for helm users to understand. But I now realize that it is rather confusing(obvious?) as helmfile.yaml isn't version-controlled yet, hence it is different than helm chart's Some more thoughts:
Forgive me about I'm not yet sure what the best name would be. |
@sstarcher I believe it would be very nice to have. Several questions came up in my mind:
|
Allow recursive include - prod_helmfile.yaml includes stage_helmfile.yaml includes dev_helmfile.yaml - will be good (see #29). |
I'm very concerned about the complexity of inclusion and recursive inclusions. |
@osterman if the helmfiles are executed in order by filename (alphanumeric?), this seems like it'd work. Consistent ordering would be very important to us. I think this would still play nicely with Github code owners as well. |
Yea, I think they should be executed lexicographically. To influence the order of execution, one could organize files like this:
|
@AssafKatz3 Hey! First of all, #227 allows you to import arbitrary yaml files into |
@AssafKatz3 PTAL at #254 too. It proposes a feature that is very similar to includable helmfiles. |
This issue is satisfied by the new helmfile directory support. Thanks to all who contributed to make that happen! |
It would be really nice if there was a notion of an include'able sub-helmfile. This would help us segment a cluster's workload definition by department, topic, or whatever else.
I am not at all tied to any particular implementation, but here's an example:
How this might work:
helmfile.yaml
are addedhelmfile.yaml
releases
andrepositories
(I think we have to ignorecontext
, as that could muck things up a bit).instances
). You still can't have multiple releases of the same name within a single hemlfile, as that'd be invalid yaml.includes
helmfiles are parsed and loaded into memory, we return to the mainhelmfile.yaml
and load itsreleases
. Again, since this is the last in line, the root helmfile can override anyreleases
in theincludes
helmfiles.Other notes:
cc @foklepoint
The text was updated successfully, but these errors were encountered: