Bug 972639 - recipe_status from ditribution/reservesys has no output
Summary: recipe_status from ditribution/reservesys has no output
Alias: None
Product: Beaker
Classification: Retired
Component: tests
Version: 0.12
Hardware: Unspecified
OS: Unspecified
unspecified vote
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-10 09:57 UTC by Petr Janda
Modified: 2018-02-06 00:41 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-06-13 06:57:25 UTC

Attachments (Terms of Use)
recipe_status.patch (1.12 KB, patch)
2013-06-10 09:57 UTC, Petr Janda
no flags Details | Diff
reservesys.patch (1.88 KB, patch)
2013-06-13 06:35 UTC, Petr Janda
no flags Details | Diff

Description Petr Janda 2013-06-10 09:57:06 UTC
Created attachment 759127 [details]

Description of problem:

recipe_status from ditribution/reservesys outputs only usage issues but provide no information about processing xmlrpc. Even when it exits with non-zero exit code it doesn`t print why.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. append to your favorite recipe 
<task name="/distribution/reservesys" role="STANDALONE">
<param name="RESERVE_IF_FAIL" value="1"/>
<param name="RESERVETIME" value="6"/>
2. explore logs

Actual results:
no messages related to obtaining recipe status are present

Expected results:
log contains info about recipe status obtaining 
used lab-controller 
obtained recipe status
info about exit status

Additional info:
small UNTESTED patch attached

Comment 2 Dan Callaghan 2013-06-12 23:00:51 UTC
It looks like /distribution/reservesys is working fine here. You passed RESERVETIME=6 which means the system is only reserved for 6 seconds. :-)

The next release of Beaker has many docs improvements, including a section about these "Beaker-provided" tasks which explains the RESERVETIME parameter. You can see the development version of the docs here:


Comment 3 Petr Janda 2013-06-13 06:33:05 UTC
OK, RESERVETIME was set to 6 seconds only, but RESERVE_IF_FAIL was set too.

It means that /distribution/reservesys should obtain current recipe status and if status is "pass" exit with pass status instead of reservation. 
But reservesys continued as if recipe status is fail.

Comment 4 Petr Janda 2013-06-13 06:35:11 UTC
Created attachment 760483 [details]

Comment 6 Nick Coghlan 2013-06-13 06:56:49 UTC
RESERVETIME is *also* used to determine how long to extend the external watchdog when starting the reservesys task. The harness state updates and the XML-RPC call up to the proxy and hence back to the main Beaker server to determine the recipe result could easily reach the 6 seconds allocated here.

The reason there's no output from the reservesys task is because it didn't fail - it got aborted by the external watchdog and had its machine taken away (this is reported in the Beaker UI, not the logs).

We're going to provide a harness independent reservation mechanism that also works for alternative harnesses and tasks that have been aborted rather than failing (see bug 639938).

While the reservesys task *could* enforce a minimum time limit for the reservation, we're not inclined to tinker with it when we could put that time into the replacement mechanism is instead.

Comment 7 Dan Callaghan 2013-06-13 07:08:09 UTC
(In reply to Nick Coghlan from comment #6)
> The reason there's no output from the reservesys task

Petr's point in comment 5 is that there *is* output from the reservesys task and you can see that it did in fact try to reserve the system (though only for ~1 minute due to the RESERVETIME=6 parameter) even though the recipe had passed and so reservesys should have silently passed immediately.

The recipe_status script in reservesys will spew a traceback if something goes actually wrong while checking the recipe status. I think what is happening here is that the recipe status is not yet known at the time it checks, because of the delay from update_dirty_jobs (new in Beaker 0.12). There is a small window of time after the previous task finished in which the result would still stay at New. In that case the recipe_status script succeeds, but New != Pass so it is counted as a failure.

I think the right answer here is bug 639938 anyway, because it will difficult and awkward to handle the delayed result in the reservesys task itself.

Note You need to log in before you can comment on or make changes to this bug.