-
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
Any way to get helmfile status to filter out irrelevant tiller args? #210
Comments
Thanks for trying helmfile. Good catch! The easiest fix for it would be to omit all the custom @rmartinez3 On the way towards the fix, I guess we get to modify your implementation of |
@mumoshu that solution does not get around args that are not supported by say |
@sstarcher Certainly! I found something similar while implementing Maintaining lists of relevant args would require comparable amount of code to make them first class args under Now the plan is:
After that, @irlevesque's example would turn into something like this: helmDefaults:
tillerNamespace: {{ env "DEPLOY_ENV" }}
releases:
- name: myapp
chart: ...
wait: true
recreatePods: true
timeout: 600
force: true Note that |
@mumoshu fine by me to change implementation. Makes sense for helm defaults to only take account of global args. And separate other flags like you explained. |
supporting timeouts and other values directly at the release makes perfect sense, but also supporting them as global for a single helmfile can also be very useful. |
Sounds nice. Just to make sure I got it right, do you want it even though we can use yaml anchor? defaults: &defaults
wait: true
releases:
- <<: *defaults
name: myapp
chart: ... |
an anchor would be less labor intensive, but having it as a global would be more useful. My specific usecase is I have a multiple helmfiles in a helmfile.d directory. Each contains different groups, but say I have this one helmfile in the directory that contains 50 copies of service X. Service X needs a --wait and a timeout. With the anchor example I would have to duplicate that on 50 extra lines, but with a global top level default I could just say all service X's in this file have --wait and --timeout of Y. Having 50 services of X is a real usecase I have. Certainly doable with the anchor example. |
@sstarcher Makes sense! Thanks. Btw, you've included |
@mumoshu that as just a random example. My specific use-case was for controlling hooks.
|
Opened #229 and #230 respectively. I'm closing this after resolving the two issues. @sstarcher Would you like to have a better support for your use-case of the default Perhaps it would be to enhance Anyway, I'd appreciate if you could submit an another feature request for it 👍 |
@irlevesque Hey! Could you rewrite your helmfile.yaml to: helmDefaults:
tillerNamespace: {{ env "DEPLOY_ENV" }}
wait: true
recreatePods: true
timeout: 600
force: true And now, you can even replacec helmDefaults:
tillerNamespace: {{ .Environment.Name }}
wait: true
recreatePods: true
timeout: 600
force: true |
Closing as resolved, but please feel free to reopen if it doesn't work for you. |
* upgrade build-harness to 0.31.1 and geodesic to 0.123.1. * Fix `gcloud-login.sh` to only call `gcloud auth login` once. * update `helmDefaults` with the suggested workaround from github.com/roboll/helmfile/issues/210.
I'm specifying tiller args as documented in the readme, via:
When I run a
helmfile status
, however, it fails with:Is there a recommended way to include the sync flags separately from delete / status flags?
The text was updated successfully, but these errors were encountered: