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#L129
> ):
> # 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.


Cheers
-- 
Rémi Duraffort
LAVA Team, Linaro