Bug 786496

Summary:	RFE: Make reserve from selection of hosts
Product:	[Retired] Beaker	Reporter:	Marian Csontos <mcsontos>
Component:	web UI	Assignee:	Raymond Mancy <rmancy>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	0.8	CC:	bpeck, dcallagh, ebaak, mcsontos, rmancy, stl
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-02 05:40:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Marian Csontos 2012-02-01 15:28:13 UTC

Description of problem:
When looking for some HW, one goes to Beaker Web UI and then can filer until the selection is fine. It would be nice having [Reserve on Any] link to schedule reserve workflow on any of the available systems meeting filter criteria. It could work from Reserve Workflow page like this:

1. Select Distro
2. Press [Select Systems]
3. Filtering...
4. Press [Reserve Any]

Comment 1 Raymond Mancy 2012-02-01 22:46:57 UTC

So this would essentially be the same as what the 'Show Systems' button allows us to do, with the exception that instead of the user being forced to pick a single system at the end of it, that final decision is taken out of their hands? Is that right?

Comment 2 Marian Csontos 2012-02-01 23:18:22 UTC

With the exception of the ability to filter systems yes.

Someone is looking for certain HW, and will end up with 10 or 20 systems. Picking one does not work well, as that particular system may block for a long time, so user would decide to queue 10 jobs - certainly behavior we should prevent.

Instead it should be allowed to queue a recipe which would not be restricted to a single system, but rather whole set of systems. It works now, with hand crafting the XML

Comment 3 Dan Callaghan 2012-10-02 05:40:36 UTC


*** This bug has been marked as a duplicate of bug 756101 ***