-
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
Question: How to handle global variables across helmfiles #398
Comments
@AndresPineros Hey! Thanks for trying helmfile. I've asked about global variables several times so far, and I do understand those and your use-cases are important. Back to the question, one possible way would be to use an environment variable that points to a kind of "base directory" containing $ SOME_BASE_DIR=$(PWD)/values/globals.yaml helmfile apply Your second sub-helmfile would look like: ....
releases:
- name: myrelease2
namespace: default
chart: mycharts/mychart
version: 0.1.0
values:
- regex: {{ list (requiredEnv "SOME_BASE_DIR") "globals.yaml" | join "" | readFile | fromYaml | getOrNil "dotnet.regex" }} You'll be interested in #245 or more extremely using an external tool like kapitan 140, for reducing the amount of boilerplate code like this.. 😃 |
More thoughts:
|
How about adding a template function With that you can place |
@sstarcher @osterman Do you any experience that made you wanting global variables? How do you deal with it? |
Could this not be solved by So one issue I have with my current use of globals is that it does not play nice with something like Atlantis. If you change a global it effects all releases not just a local change. |
Good point! environments:
default:
values:
- ../../../globals.yaml My idea is that environments:
default:
values:
- {{ findUpward "globals.yaml" }} |
Similarly to what happens when you use terraform modules and updates to the modules doesn't trigger changes to dependent tf projects? I was in the impression that atlantis suggests us to use version: 2
projects:
- dir: project1
autoplan:
when_modified: ["../modules/**/*.tf", "*.tf*"] https://www.runatlantis.io/guide/atlantis-yaml-use-cases.html#configuring-autoplanning |
I don't have that issue due to separating out our terraform modules. I do the following.
We don't allow floating things and everything is versioned so that atlantis workaround is not required and people know EXACTLY what is being updated instead of effecting multiple services at once. Which is the exact issue a global introduces where you make a change and it breaks something you know nothing about. |
Makes sense! So an equivalent way to manage globals in helmfile would be to version your gloabls.yaml with unique IDs. A poor man's implementation would look like:
And you reference a single version of globals.yaml(v1 or v2 or whatever) explicitly in your helmfile.yaml, so that people know EXACTLY what's being updated and why. |
I would lean toward recommending using templating and environments.
|
@AndresPineros Would you be interested in #388 (comment)? |
Since #587, you can use Creating and importing a shared layer from many state files will give you the similar end result as global variables. Also, environment variables can be used as global variables, as before. I think this can be closed as resolved. WDY? |
Please feel free to reopen if necessary 😃 |
To me the environment section is there to specify environment specific values and not global values to be reused by any templating part. |
@sgandon Thanks! Would you mind clarifying a bit more on this:
Mind giving me examples on what would you use globals and environment values for? If you don't use environnment specific values for any templating(I read your comment so), what would you use for? |
@sgandon Probably this isn't what you're trying to say, but anyway - I wondered if we can add something like The use of
Would the |
cc/ @davidovich |
@davidovich I'm considering to deprecate double rendering in favor of the new layering (#587) and globals. And I wanted to discuss with you as the original author of the double rendering feature 😃 WDYT? |
I can reply tomorrow (it's near bedtime in Montreal) and I will think about
it.
…On Tue, May 28, 2019 at 9:32 PM KUOKA Yusuke ***@***.***> wrote:
@davidovich <https://github.com/davidovich> I'm considering to deprecate
double rendering in favor of the new layering (#587
<#587>) and globals. And I wanted
to discuss with you as the original author of the double rendering feature
😃 WDYT?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#398?email_source=notifications&email_token=AAK7U4T6KXFBKOLN66EZPITPXXMK5A5CNFSM4GDKOK2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWN4Y3Y#issuecomment-496749679>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAK7U4SGZEV2I3VRPQISA7DPXXMK5ANCNFSM4GDKOK2A>
.
|
I used to have a use case for global values that I worked around with environment variables cause we have build a tool around helmfile that can create those environment variables. |
@sgandon Thanks for the response! I would use either (1) environment "values" and explicit inheritance (#523) OR (2) Regarding
Even so, would you use the proposed |
To clarify - "explicit inheritance" will be enabled via |
@mumoshu something like
and the command line would allow of course to specify the env to use but also use a --set to specify specific env key values. |
@sgandon Ah, that's definitely an interesting idea! So we need:
Your use-case needs 1 and 2. And overall we need 1, 2 and 3 to possibly serve everyone's use-case, right? |
hummm, not sure to understand you proposal.
I really would appreciate my initial proposal if possible and not create another fixed env definition. |
@sgandon I think I'm following you. I'm in the impression that just changing helmfile to treat Let's say |
So what's I'm proposing is making |
I absolutly agree with this proposal, this is indeed what I was expecting when I first go to work with helmfile. So this feels very natural although it break the current behaviour. |
@sgandon Thanks as always for your patience and support! Great we could agree on the thing
Yeah this was a concern for me as well. I have two options right now. (1) Go head with changing the behavior, believing it won't break anything in real use-cases. You usually don't have extra keys in (2) Think big and redesign environment values. This has good side-effects on other issues like #361 while not breaking existing behavior at all. #361 (comment) |
looking that you #361 comment, this is great ! solution 2 is much more natural and what everyone is waiting for (I believe :) ). |
To avoid duplication I'm looking for #define equivalent of some constant eg something like globals:
thanos-version: v0.20.1 then in 2 different release sections releases:
- name: prometheus
values:
sidecarContainers:
- name: thanos-sidecar
image: quay.io/thanos/thanos:{{.globals.thanos-version}}
- name: thanos
version: {{.globals.thanos-version}} And this irrespective of environment (ie not duplicated unless it needs to be different; a real default value) ps: this might be more an faq/doc question than a request but this issue is where "helmfile shared variables" googling lands |
@ldemailly for the above I was able to use a Go template variable: {{$chartsBasePath := env "CHARTS_BASE_PATH" | default "../../../libraries/helm"}}
releases:
- name: "my-chart"
chart: "{{$chartsBasePath}}/my-chart"
- name: "my-other-chart"
chart: "{{$chartsBasePath}}/my-other-chart" |
Is it possible to share global variables between helmfiles in the following manner?
Let's say I have one global variables file called
globals.yaml
, that has this content:And multiple helmfiles that depending on what we want can grab the spring or the dotnet value (this is what I want to know if is possible):
and
So basically for each release, I can pass the global variable I want to a variable that is already defined in the chart.
Is there a way to do this or simulate this behavior?
The text was updated successfully, but these errors were encountered: