This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 983037 - RFE/BUG: take host specification into account when scheduling jobs
RFE/BUG: take host specification into account when scheduling jobs
Status: NEW
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.13
Unspecified Unspecified
high Severity high (vote)
: ---
: ---
Assigned To: beaker-dev-list
tools-bugs
: FutureFeature
Depends On: 1127129
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-10 07:03 EDT by Alexander Todorov
Modified: 2016-05-26 09:23 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexander Todorov 2013-07-10 07:03:01 EDT
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 03:30:28 EDT
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-07 21:47:08 EDT
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.