Remi Duraffort remi.duraffort@linaro.org writes:
Hello Kevin,
Le mar. 30 avr. 2019 à 21:00, Kevin Hilman khilman@baylibre.com a écrit :
Remi Duraffort remi.duraffort@linaro.org writes:
Hello,
the timeout is computed by taking (see
https://git.lavasoftware.org/lava/lava/blob/master/lava_dispatcher/action.py...
): # 1/ the global action timeout # 2/ the individual action timeout # 3/ the action block timeout
So a workaround is maybe (I haven't tried), to remove the deploy action timeout. So the default action timeout will be used for that deploy
action
and the http-download action timeout will be used for http-download. This really hacky but that might work :(
I tried, but it doesn't work either.
I removed the timeout from the deploy section, and then I tried both ways of customizing http-download as suggested by the doc:
First in the `actions` http://lava.baylibre.com:10080/scheduler/job/1862/definition#defline45
Second in the `connections': http://lava.baylibre.com:10080/scheduler/job/1863/definition#defline45
I don't think changing the "connections" timeouts will have any impacts on that part of the code.
In both cases, I set http-download timeout to 15 minutes (900 sec), but looking at the job as it runs, the http-download timeout in the job was 5 minutes.
Hum, this is really strange and buggy. I'm quite sure that the problem is coming from the way the parameters are forwarded down the pipeline + the way the timeout values are stored in the action. That's something that has to be reworked but I won't have time for that for the moment.
Unfortunately I don't see any workaround/quick fix for this issue. Sorry.
OK, can you at least file this as a LAVA bug/issue so it can eventually be fixed, or some workarounds clarified?
In the meantime, using timeouts is very confusing.
Kevin