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

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