Any way to get helmfile status to filter out irrelevant tiller args?

[irlevesque]

I'm specifying tiller args as documented in the readme, via:

helmDefaults:
  tillerNamespace: {{ env "DEPLOY_ENV" }}
  args:
    - "--wait"
    - "--recreate-pods"
    - "--timeout=600"
    - "--force"
    - "--reset-values"

When I run a helmfile status, however, it fails with:

→ DEPLOY_ENV=staging helmfile --log-level debug -l chart=app status
Getting status app-staging
exec: helm status app-staging --force --reset-values --tiller-namespace=staging --wait --recreate-pods --timeout=600
Error: unknown flag: --force

err: exit status 1

Is there a recommended way to include the sync flags separately from delete / status flags?

[mumoshu]

Thanks for trying helmfile. Good catch!
AFAIK there's no workaround for it right now.

The easiest fix for it would be to omit all the custom args for the helm commands on helmfile status.

@rmartinez3 On the way towards the fix, I guess we get to modify your implementation of getArgs to return two args - one for helm global args like --tiller-namespace that are passed to helm.SetExtraArgs, one for other args like --force --recreate-pods that is passed only to SyncReleases. Would you be ok with that? Please tell me If you had reasons to not do so. Thanks!

[sstarcher]

@mumoshu that solution does not get around args that are not supported by say helm-diff plugin through right? To do that we would likely have to make the args first class. Or at least keep a list of relevant args.

[mumoshu]

@sstarcher Certainly! I found something similar while implementing wait: true in helmfile.yaml https://github.com/roboll/helmfile/pull/222/files#r212160642

Maintaining lists of relevant args would require comparable amount of code to make them first class args under releases[], like I did for wait. And I believe first class args are generally easier to read and write.

Now the plan is:

• Recommend to use helmDefaults.args only for global helm args
• Make force, recreate-pods and timeout first class args under releases[]

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 --reset-values can be safely omitted from your helmfile.yaml, because helmfile always provide the flag to helm.

[rmartinez3]

@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.

[sstarcher]

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.

[mumoshu]

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: ...

[sstarcher]

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.

[mumoshu]

@sstarcher Makes sense! Thanks.

Btw, you've included --set image.tag in args in #212. You did that in order to avoid repeating the same sets for all releases, right?

[sstarcher]

@mumoshu that as just a random example. My specific use-case was for controlling hooks.

--set app1.bootstrap=true,app2.bootstrap=false

[mumoshu]

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 --sets?

Perhaps it would be to enhance helmDefaults to accept some inline values that are propagated to all the releases?

Anyway, I'd appreciate if you could submit an another feature request for it 👍

[mumoshu]

@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 DEPLOY_ENV by using #267:

helmDefaults:
  tillerNamespace: {{ .Environment.Name }}
  wait: true
  recreatePods: true
  timeout: 600
  force: true

[mumoshu]

Closing as resolved, but please feel free to reopen if it doesn't work for you.