Bug 983037 - RFE/BUG: take host specification into account when scheduling jobs
Summary: RFE/BUG: take host specification into account when scheduling jobs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Beaker
Classification: Retired
Component: scheduler
Version: 0.13
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On: 1127129
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-10 11:03 UTC by Alexander Todorov
Modified: 2020-11-19 22:01 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-11-19 21:58:10 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.