Helmfile: helmDefaults attributes "wait" and "timeout" seem ineffective

Created on 30 Oct 2020  路  4Comments  路  Source: roboll/helmfile

Hi,

I've spotted a strange behaviour with helmfiles. Indeed I would like that my helmfile don't wait for my deployment and my pod ready to proceed all of it actions.

Maybe I misunderstood the purpose of wait and timeout in helmDefaults attribute but it seem that wait is like a --wait flag and it's set to false by default.

I tried all the following parameters in my helmfile and I get the same behaviour for all configuration :

cleanupOnFail: true recreatePods: true wait: false timeout: 0 force: false historyMax: 3

cleanupOnFail: true recreatePods: true wait: false force: false historyMax: 3

cleanupOnFail: true recreatePods: true force: false historyMax: 3

cleanupOnFail: true recreatePods: true wait: true force: false historyMax: 3

For all the configuration that's what I get in my terminal :

image

Does somebody else facing the same issue ?

Thanks, 馃槉

Most helpful comment

Hi,

I am also using v3.3.4 and for me timeout seems to always get set to the default value.

Issue I pointed out was not a fix for this issue, but thought let's highlight it since they might be related.

All 4 comments

Hi,

It seems I am bumping into a similar issue just now, are you using helm 3.x?

Timeout input in helm has changed in version according to docs.

v2.x: --timeout int Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300)

v3.x: --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)

Now also see the following issue raised: https://github.com/roboll/helmfile/issues/863, which should be resolved. But it might be related.

In releases specifying timeout and wait works so seems unrelated. Anybody any ideas?

Greets

Hi,

Actually I am using helm v3.3.4.

I've missed this issue (#863) but it seems that the fix didn't solved the ineffective wait: false argument.

By the way, thanks for your answer !

Hi,

I am also using v3.3.4 and for me timeout seems to always get set to the default value.

Issue I pointed out was not a fix for this issue, but thought let's highlight it since they might be related.

Also facing this issue, using Helm 3.3.4

I'm assuming this switch is supposed to have some conditions based on it as well? ie if a Job/Cron completes or fails etc?

Also is it supposed to in theory wait until the specific release is finished to move onto the next one?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sstarcher picture sstarcher  路  3Comments

madAndroid picture madAndroid  路  3Comments

maver1ck picture maver1ck  路  3Comments

mumoshu picture mumoshu  路  4Comments

RafalMaleska picture RafalMaleska  路  3Comments