Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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: NEW
Alias: None
Product: Beaker
Classification: Community
Component: scheduler
Version: 0.13
Hardware: Unspecified
OS: Unspecified
high
high vote
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: 2018-11-09 23:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:


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.