Description of problem: [16:25] <mbrodeur> bpeck: I think someone's used this feature to create an un-returnable system. [16:25] <mbrodeur> https://beaker.engineering.redhat.com/view/dell-per210-01.lab.bos.redhat.com [16:26] <mbrodeur> The return error refers to a deleted recipe. Canceling what would have been the right job number gives a successful result but the machine it still reserved. [16:27] <bpeck> mbrodeur: I'm not sure what the chain of events are that gets us in this state [16:27] <bpeck> mbrodeur: they shouldn't be able to delete a job that is still active [16:28] <bpeck> the way I get around it for now is: [16:28] <bpeck> 1) use bkr job-results R:RECIPID to find out the recipesetID [16:28] <bpeck> 2) bkr job-cancel RS:recipesetID [16:28] <bpeck> I did that just now to that recipe [16:29] <bpeck> mbrodeur: you want to capture this irc session and open a bz The root of the issue is that systems can remain assigned to a user after a job is complete. I think there's a separate bug for that. In this particular case, a completed job can be deleted while there's still a system that thinks it's being used. The job being deleted makes it more difficult, but not impossible, to free the system.
I think this is the same as bug 715226.
*** This bug has been marked as a duplicate of bug 715226 ***