Description of problem: If all of the systems available to a queued recipe are marked 'Broken' after the recipe is queued but before it is scheduled, the recipe will never progress. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Queue two recipes that both use the same system. 2. When R1 is running and R2 queued, mark R1's system as broken. 3. Cancel R1 Actual results: R2 remains queued Expected results: R2 should abort Additional info: This is because schedule_queued_recipes() only considers recipes that have systems that are 'Automated'. One way to deal with this, would be to remove the system status check in the query, and then just deal with broken systems the same way we deal with systems that the user no longer has permission with. In this way, the system would be removed and picked up by abort_dead_recipes()
Will we also hit this if a recipe is queued while an automated system is on loan, but extra restrictions (like shared=False or a group setting) are added before the loan is released?
If the loan is returned the system will then become available for the recipe. Before the recipe is actually scheduled though, it checks whether it still has the correct permissions for this system. If it does not, it is removed as a candidate system. Once candidate systems equal zero, it is picked up by aborted_dead_recipes()
http://gerrit.beaker-project.org/#/c/2064/
Steps to reproduce: 1. Queue two recipes, both useing the one same system 2. R1 will start and R2 will be queued 3. Then set that status of the system to Broken 4. Cancel R1 5. R2 should not remain queued, but should become Aborted
^ Steps to verify fix rather.
Beaker 0.15 has been released.
This change has been nominated to be back ported to the 0.14 branch, to be released as part of the next maintenance release 0.14.2.
Adjusting target milestone to make the changes backported to 0.14.2 easier to identify. 0.15.0 has enough significant regressions that it shouldn't be used, so the change means that 0.15.1 can be effectively reidentified as the union of that tag and the 0.14.2 target milestone.
Closing as addressed in Beaker 0.14.2.