Hello,
I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win.
Based on the doc, I did this, I added the following to my job[2]
timeouts: actions: http-download: minutes: 15
However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout.
I got the same result when tryin to use timeouts: connections:
What am I missing?
Kevin
[1] https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_do... [2] https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44 [3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1
On Mon, 29 Apr 2019 at 22:54, Kevin Hilman khilman@baylibre.com wrote:
Hello,
I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win.
Based on the doc, I did this, I added the following to my job[2]
timeouts: actions: http-download: minutes: 15
However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout.
I got the same result when tryin to use timeouts: connections:
What am I missing?
I'm not 100% sure but the timeouts defined in the 'timeouts' section are considered 'default' and are always overwritten by timeouts defined in actions themselves.
milosz
Kevin
[1] https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_do... [2] https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44 [3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
Hi Milosz and Kevin,
let me explain the issue a bit:
we want to use failure_retry: 2 in the deploy section.
But for that we need the overall deployimages timeout to be let's say 25 minutes and the http_download timeout to be e.g. 10 minutes. Currently everything is 25 minutes.
So do I understand this right, that - deploy: timeout: minutes: 25 Overrides all timeout below 'deploy' to 25 minutes ?
So would we have to remove that in favour of a more detailed setting of the top-level: timeouts: job: minutes: 80 action: minutes: 15 connection: minutes: 5 connections: lava-test-shell: minutes: 10
????
On Tue, Apr 30, 2019 at 10:02 AM Milosz Wasilewski < milosz.wasilewski@linaro.org> wrote:
On Mon, 29 Apr 2019 at 22:54, Kevin Hilman khilman@baylibre.com wrote:
Hello,
I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win.
Based on the doc, I did this, I added the following to my job[2]
timeouts: actions: http-download: minutes: 15
However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout.
I got the same result when tryin to use timeouts: connections:
What am I missing?
I'm not 100% sure but the timeouts defined in the 'timeouts' section are considered 'default' and are always overwritten by timeouts defined in actions themselves.
milosz
Kevin
[1]
https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_do...
[2]
https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44
[3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
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 :(
Rgds
Le mar. 30 avr. 2019 à 16:15, Jan-Simon Moeller < jsmoeller@linuxfoundation.org> a écrit :
Hi Milosz and Kevin,
let me explain the issue a bit:
we want to use failure_retry: 2 in the deploy section.
But for that we need the overall deployimages timeout to be let's say 25 minutes and the http_download timeout to be e.g. 10 minutes. Currently everything is 25 minutes.
So do I understand this right, that
- deploy:
timeout: minutes: 25 Overrides all timeout below 'deploy' to 25 minutes ?
So would we have to remove that in favour of a more detailed setting of the top-level: timeouts: job: minutes: 80 action: minutes: 15 connection: minutes: 5 connections: lava-test-shell: minutes: 10
????
On Tue, Apr 30, 2019 at 10:02 AM Milosz Wasilewski < milosz.wasilewski@linaro.org> wrote:
On Mon, 29 Apr 2019 at 22:54, Kevin Hilman khilman@baylibre.com wrote:
Hello,
I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win.
Based on the doc, I did this, I added the following to my job[2]
timeouts: actions: http-download: minutes: 15
However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout.
I got the same result when tryin to use timeouts: connections:
What am I missing?
I'm not 100% sure but the timeouts defined in the 'timeouts' section are considered 'default' and are always overwritten by timeouts defined in actions themselves.
milosz
Kevin
[1]
https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_do...
[2]
https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44
[3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
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 `connecttions': http://lava.baylibre.com:10080/scheduler/job/1863/definition#defline45
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.
So, not only is my 15 minutes not taking effect, I'm not even sure where the 5 min timeout is coming from.
Kevin
Hi Remi,
Any more thoughts on what the right way to do this is?
Kevin
Kevin Hilman khilman@baylibre.com writes:
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 `connecttions': http://lava.baylibre.com:10080/scheduler/job/1863/definition#defline45
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.
So, not only is my 15 minutes not taking effect, I'm not even sure where the 5 min timeout is coming from.
Kevin
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.
Cheers
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
Hello Kevin,
see the issue: https://git.lavasoftware.org/lava/lava/issues/280
Rgds.
Le mar. 21 mai 2019 à 20:04, Kevin Hilman khilman@baylibre.com a écrit :
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
lava-users@lists.lavasoftware.org
-
Jan-Simon Moeller -
Kevin Hilman -
Milosz Wasilewski -
Remi Duraffort