Bug 983037

Summary: RFE/BUG: take host specification into account when scheduling jobs
Product: [Retired] Beaker Reporter: Alexander Todorov <atodorov>
Component: schedulerAssignee: beaker-dev-list
Status: CLOSED WONTFIX QA Contact: tools-bugs <tools-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 0.13CC: cbouchar, qwan, tools-bugs
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-19 21:58:10 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:
Bug Depends On: 1127129    
Bug Blocks:    

Description Alexander Todorov 2013-07-10 11:03:01 UTC 
Description of problem:

JOB 448395 requires a specific host to run:

<hostRequires>
	<and>
		<hostname op="=" value="hp-rx2660-01.rhts.eng.brq.redhat.com"/>
		<system_type op="=" value="Machine"/>
	</and>
</hostRequires>


JOB 448236 doesn't require any specific hosts but picked up the same system required by JOB 448395. Now 448395 is still waiting b/c the previous job is taking too long to complete. (which is another issue).


Please fix it. 

Possible test scenario: 

1) Schedule multiple jobs against ia64 or another less common architecture
2) The number of jobs needs to be higher than the pool of available systems. This will cause all free systems to become busy while leaving some jobs waiting. 
3) Schedule a job against any of the available systems. 


Expected results: 

X < Y < Z

Job X will be executed on example.com 
Job Y and Job Z will be waiting

As Job X completes, the host example.com will become free and Job Z will be executed before Job Y.
Comment 2 Nick Coghlan 2013-07-11 07:30:28 UTC 
This isn't practical given the current scheduler architecture, but is something we might be able to consider once the revised scheduler design (which avoids looping over the MxN cross product of all queued recipes and systems by instead only looking at those systems which recently became available) has been put in place.

However, the scheduler update is at least a few months away :(
Comment 3 Nick Coghlan 2014-08-08 01:47:08 UTC 
This is on hold until we evaluate the possibility of switching to a more capable scheduling engine.