Bug 972290
Summary: | Beaker shows a 500 error when cancelling a job while it is being scheduled | ||
---|---|---|---|
Product: | [Retired] Beaker | Reporter: | xjia <xjia> |
Component: | command line | Assignee: | Amit Saha <asaha> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Dan Callaghan <dcallagh> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | develop | CC: | asaha, dcallagh, ebaak, llim, qwan, rglasz, rmancy, xtian |
Target Milestone: | 0.13 | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-06-25 06:27:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
xjia
2013-06-08 07:27:36 UTC
We should be catching this and issuing a rollback. On Gerrit: http://gerrit.beaker-project.org/#/c/2022/1 It is to be noted that this isn't a fix by any means. It simply returns a nice error message to the user. The real fix would be to cancel the job, considering that some other DB transaction may be in progress and accounting correctly for it. Verified: 1. Submitted two jobs at the same time. 2. Watched the beakerd logs until the first recipe was scheduled by schedule_queued_recipes ("Created watchdog for recipe id: ...") 3. Hit the "Yes" button on the cancel page for the first recipe, before beakerd finished schedule_queued_recipes. Saw a pleasant flash message saying: "Could not cancel job id 568. Please try later" instead of a 500 error. The schedule_queued_recipes routine is the only window large enough to ever hit this problem, since it is the only one which does all its work in one big transaction, and takes several seconds for each recipe. (In reply to Dan Callaghan from comment #4) > The schedule_queued_recipes routine is the only window large enough to ever > hit this problem, since it is the only one which does all its work in one > big transaction, and takes several seconds for each recipe. This ticket was filed against 'Updating' to 'Running', which is not the schedule_queued_recipes routine. The update_dirty_jobs routine would have caused this original condition I would think. (In reply to Raymond Mancy from comment #5) > This ticket was filed against 'Updating' to 'Running', which is not the > schedule_queued_recipes routine. > > The update_dirty_jobs routine would have caused this original condition I > would think. update_dirty_jobs doesn't change recipe-task status, only recipe, recipe set, and job status (as well as computing results and counts and returning systems, etc). So cancelling cannot conflict with update_dirty_jobs. I'm guessing that in Xuan's original report when he said ‘trying to change from "Updating" to "Running"’ he just meant ‘while beakerd was scheduling the recipe’. (In reply to Dan Callaghan from comment #6) Actually. I just described what I had done before it happened. Not sure what cased this problem. It's difficult to reproduce it. but I think you could guess or image what had happened from the code stack. Beaker 0.13.1 has been released. |