Bug 1016101 - reserve workflow should provide option to specifically choose/avoid VMs
reserve workflow should provide option to specifically choose/avoid VMs
Status: NEW
Product: Beaker
Classification: Community
Component: inventory (Show other bugs)
0.15
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: beaker-dev-list
tools-bugs
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-07 09:43 EDT by Corey Welton
Modified: 2018-02-21 23:39 EST (History)
5 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 Corey Welton 2013-10-07 09:43:15 EDT
Description of problem:
When testing certain features/products which require provisioning (from/on the box provided by beaker), I require hardware itself, not a VM, i.e., 'nested virtualization' is not an option for me.

However, when reserving new systems in the Schedule | Reserve workflow, there's no option to readily filter out VMs from available selections.

I'm thinking something like a checkbox next to "Show Systems" and "Auto Pick System" would be appropriate.  Something like

[x] (Virtual Hardware OK)

This would be checked by default, and would be applied to either submit, showing only baremetal, as opposed to any VMs.

For "Show Systems", all VMs would be filtered out of results
for "Auto Pick System, it would be applied to the subsequent Queue Job action, assuring no such systems are selected.

I am not sure what on the backend would be required, if anything, for beaker to know whether they are hardware/VMs, and/or what each inventory system might have to report back to beaker for it to determine type.
Comment 1 Corey Welton 2013-10-07 09:46:25 EDT
clarification: 

"[x] (Virtual Hardware OK)

This would be checked by default, and would be applied to either submit, showing only baremetal, as opposed to any VMs."

should read

"[x] (Virtual Hardware OK)

Rather, this should be checked by default.  But if unchecked, user would see only baremetal, as opposed to any VMs."
Comment 3 Dan Callaghan 2013-10-07 19:58:17 EDT
Beaker will filter out virtual systems if you add this to the <hostRequires/> of your recipe:

<hypervisor op="=" value=""/>

It's buried in our docs here:

http://beaker-project.org/docs/user-guide/job-xml.html

However there's no way to specify that (or any other hostRequires) from the reserve workflow page.
Comment 4 Nick Coghlan 2013-10-07 20:16:03 EDT
For manually selecting a system, the "Show Systems" options already allows this to be handled through the usual system search options. For the bare metal case, that means specifying "System/Hypervisor is <blank>" (unfortunately, bug 902617 means you also need to specify a criterion for System/LastInventoried to exclude systems that have never had inventory date collected).

It would be nice to be able to specify a hostRequires snippet for the "Auto Pick System" use case, but the fact that there's already an existing manual workaround pushes this one a fair way down the priority list.
Comment 5 Nick Coghlan 2013-10-07 20:17:56 EDT
Sorry, transposed a couple of digits in that bug reference. The relevant one is bug 912607 (where we'd like to automatically exclude uninventoried systems from inventory dependent searches)
Comment 6 Nick Coghlan 2014-07-25 03:10:18 EDT
We likely won't implement bug 912607 any time soon (see the discussion on the bug), but the implementation of bug 949777 made it possible to explicitly exclude uninventoried systems from XML filters as well.

Supplying additional filtering criteria for "Auto pick system" in the reserve workflow remains the only aspect of this which isn't already covered.
Comment 7 Dan Callaghan 2017-01-11 21:58:12 EST
I suspect we will discover a need for this shortly after 24.0 goes live...

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