Bug 972639 - recipe_status from ditribution/reservesys has no output
recipe_status from ditribution/reservesys has no output
Status: CLOSED WONTFIX
Product: Beaker
Classification: Community
Component: tests (Show other bugs)
0.12
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: beaker-dev-list
tools-bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-10 05:57 EDT by Petr Janda
Modified: 2018-02-05 19:41 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-13 02:57:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Petr Janda 2013-06-10 05:57:06 EDT
Created attachment 759127 [details]
recipe_status.patch

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):

0.12.1

How reproducible:

always

Steps to Reproduce:
1. append to your favorite recipe 
<task name="/distribution/reservesys" role="STANDALONE">
<params>
<param name="RESERVE_IF_FAIL" value="1"/>
<param name="RESERVETIME" value="6"/>
</params>
</task>
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 19:00:51 EDT
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:

http://beaker-project.org/docs-develop/user-guide/beaker-provided-tasks.html#distribution-reservesys
Comment 3 Petr Janda 2013-06-13 02:33:05 EDT
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 02:35:11 EDT
Created attachment 760483 [details]
reservesys.patch
Comment 6 Nick Coghlan 2013-06-13 02:56:49 EDT
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 03:08:09 EDT
(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.