Bug 903930

Summary: recipe for system with no power control can remain stuck in Waiting forever
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: schedulerAssignee: beaker-dev-list
Status: CLOSED EOL QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 0.11CC: agk, lalityadev321, mastyk, qwan, tools-bugs
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: Misc
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-21 08:46:04 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 Dan Callaghan 2013-01-25 04:52:28 UTC
Beaker supports using systems which lack automated power control (for example, a laptop) with the scheduler. In these cases it is assumed that the user will take some manual action to reboot the system and start the recipe, after Beaker has done the appropriate netboot configuration.

That works fine except if the user forgets to go and hit the power button. Beaker (intentionally?) doesn't set a watchdog kill time for such recipes. So if the recipe never starts, nothing will ever force it to be cleaned up and it will end up stuck in Waiting forever.

This is particularly problematic if the user *thinks* the system has automated power control, but it's just not configured in Beaker. In other words, Beaker doesn't know the difference between a system that lacks automated power control (like a laptop) and a system where the owner just forgot to configure it.

At a bare minimum, we should probably set a really generous initial watchdog kill time for such recipes, to catch cases where the user forgets to reboot and then the system is reserved for weeks on end doing nothing.

Comment 3 Martin Styk 2020-04-21 08:46:04 UTC
Closing this issue.
We are not planning to address this problem in the Beaker development lifecycle.

Instead of that, we are planning to continue our effort in building Beaker.NEXT.
If you have any questions, feel free to reach out to me.

Best regards,
Martin Styk