Bug 868026 - failure to install task RPM is not properly reflected in task results
failure to install task RPM is not properly reflected in task results
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: beah (Show other bugs)
0.9
Unspecified Unspecified
high Severity high (vote)
: 0.11
: ---
Assigned To: Amit Saha
Nick Coghlan
Misc
: Regression
: 877869 (view as bug list)
Depends On:
Blocks: 593663
  Show dependency treegraph
 
Reported: 2012-10-18 18:34 EDT by Dan Callaghan
Modified: 2015-07-26 18:14 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-16 23:34:23 EST
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)

  None (edit)
Description Dan Callaghan 2012-10-18 18:34:15 EDT
If the rpm database becomes corrupted somehow, such that beah cannot install task RPMs, the task result in Beaker appears as "Completed New" which is not really sensible. The harness should at least report the task as "Completed Failed" or better yet, simply abort the whole recipe.
Comment 2 Marian Csontos 2012-10-19 05:09:10 EDT
The task should have been aborted, which used to work fine.
What does the job-results show?
Comment 4 Dan Callaghan 2012-11-25 20:32:17 EST
*** Bug 877869 has been marked as a duplicate of this bug. ***
Comment 9 Amit Saha 2012-12-12 06:54:08 EST
As the task logs of the original bug report show, although the abort event was generated by beah, it wasn't handled correctly. Discussing with Marian Csontos, we inferred that the problem was possibly in the beaker backend - beakerlc.py. If the async_proc (on end event) sets the task to finished before
proc_evt_abort gets to it, it will return without aborting the
task. This is what possibly happened here. Hence, checking for the completed status of the task should prevent this from happening.

I couldn't ofcourse reproduce the problem when I run the job for a couple of times.

On Gerrit: http://gerrit.beaker-project.org/#/c/1563/
Comment 12 Nick Coghlan 2013-01-10 00:27:38 EST
We were never able to reproduce this - the change was made by analysis. Testing indicates that this change at least did not introduce any regressions.
Comment 13 Dan Callaghan 2013-01-16 23:34:23 EST
Beaker 0.11.0 has been released.

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