Bug 1016101 - [RFE]reserve workflow should provide option to specifically choose/avoid VMs
Summary: [RFE]reserve workflow should provide option to specifically choose/avoid VMs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Beaker
Classification: Retired
Component: inventory
Version: 0.15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-07 13:43 UTC by Corey Welton
Modified: 2020-11-19 21:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-19 21:53:47 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 912607 0 unspecified CLOSED Exclude uninventoried systems from inventory dependent searches 2021-02-22 00:41:40 UTC

Internal Links: 912607

Description Corey Welton 2013-10-07 13:43:15 UTC
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 13:46:25 UTC
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 23:58:17 UTC
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-08 00:16:03 UTC
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-08 00:17:56 UTC
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 07:10:18 UTC
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-12 02:58:12 UTC
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.