Bug 598781 - [RFE] Preferred asset group ordering in autopick
[RFE] Preferred asset group ordering in autopick
Status: NEW
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.5
All Linux
high Severity high (vote)
: ---
: ---
Assigned To: beaker-dev-list
tools-bugs
GroupModel
: FutureFeature, Reopened
Depends On: 1127129
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-01 22:59 EDT by Jeff Burke
Modified: 2016-05-26 09:31 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-11 20:50:31 EST
Type: ---
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 Jeff Burke 2010-06-01 22:59:26 EDT
Description of problem:
 Currently when scheduling tests hosts selection is not random. Speaking with Bill the order of selection is Owner, Group, Other. I would like the ability to make this selection process truly random.
Comment 1 Bill Peck 2010-10-07 15:31:03 EDT
I will have to push this to 0.5.60 since I realize we need the following implemented:

# Order systems by owner, then Group, finally shared for everyone.
# FIXME Make this configurable, so that a user can specify their scheduling
# preference from the job.
# <recipe><scheduler method='random|fair|owner|group'/></recipe>

Right now we have fair implemented and thats all.  

This change would allow jobs to be submitted with "random" and get a truly random selection.
Comment 2 Bill Peck 2010-11-05 14:31:25 EDT
I've reworked this a little..

<autopick random="True|1|False|0">
 <pool>owner</pool> <!-- add systems that you are the owner of -->
 <pool>groups</pool> <!-- add systems that you have access via group membership -->
 <pool>Public</pool> <!-- add systems that are shared to everyone -->
</autopick>

<!-- Pick me any system randomly from any of the pools -->
<autopick random="True">
 <pool>owner</pool> 
 <pool>groups</pool>
 <pool>Public</pool>
</autopick>

<!-- First try to find a system I'm the owner of, then a system that is a memeber of my groups -->
<autopick>
 <pool>owner</pool>
 <pool>groups</pool>
</autopick>

<!-- Pick me a system I own randomly  -->
<autopick random="1">
 <pool>owner</pool> 
</autopick>
Comment 3 Marian Csontos 2010-11-05 16:15:46 EDT
Could it be made to work with particular group as a parameter?

It would be useful for people who are members of multiple groups as I am, e.g. I do not want to run some tests on rare machines dedicated to storage testing. (IIUC I could use "Public" in this case, but that makes the pool smaller.)
Comment 4 Bill Peck 2010-11-05 16:20:51 EDT
Yes,  But I feel that belongs in the <hostRequires/> section.
Comment 7 Marian Csontos 2011-02-24 05:13:31 EST
(In reply to comment #2)
> <!-- First try to find a system I'm the owner of, then a system that is a
> memeber of my groups -->
> <autopick>
>  <pool>owner</pool>
>  <pool>groups</pool>
> </autopick>

This one does not work. `autopick' element without `random' attribute fails with following message:

  <Fault 1: "exceptions.AttributeError:'bool' object has no attribute 'lower'">

IMHO it should work: autopick is used for randomization as well as for picking pools and without the attribute I do not care about randomization and system should provide a reasonable default according to its settings/preference.

Shall I open a new BZ or will we name it a feature?
Comment 8 Marian Csontos 2011-02-24 05:55:45 EST
It does not work as advertised...

I have tried:

> <autopick random="1">
>  <pool>Public</pool>
> </autopick>

and it:

- still uses machines owned by a group
- it's not included in job-results and is not clone-able
Comment 9 Bill Peck 2011-02-28 12:41:52 EST
Only the random part was implemented.  The pools of systems was never done, I just wanted to make sure what ever we did implement made sense for that as well.
Comment 10 Nick Coghlan 2012-10-17 00:39:58 EDT
Bulk reassignment of issues as Bill has moved to another team.
Comment 12 Nick Coghlan 2014-08-07 21:47:13 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.