|Summary:||Scheduler->Reserve fails to list Prototype system even when Access Policies are correctly set|
|Product:||[Community] Beaker||Reporter:||Arthur Benoit <abenoit>|
|Component:||web UI||Assignee:||Dan Callaghan <dcallagh>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||tools-bugs <tools-bugs>|
|Version:||0.16||CC:||dcallagh, dowang, ebaak, rjoost|
|Target Milestone:||24.0||Keywords:||FutureFeature, Patch|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-02-21 18:50:05 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Arthur Benoit 2014-05-19 14:42:10 UTC
Description of problem: When Scheduler->Reserve is run looking for systems with "View and Reserve" access policies set; systems with "Type: Prototype" set do not show up in the reservation list. Version-Release number of selected component (if applicable): Version 0.16.2 How reproducible: Always Steps to Reproduce: 1. Distro Fill out the "Reserve Workflow" as follows: Family: RedHatEnterpriseLinux6 Tag: None Distro: RHEL-6.5 Distro Tree Lab: None Selected Distro Tree: RHEL-R.5 Workstation x86_64 Select: "Show Systems" 2. Under "Table" Select "System name" Under "Operation" select " "contains" Under "Value" select "sharkbay" Select "Search" Select: "Show Search Options" Notice that none of the sharkbay systems show up even though both the "View and Reserve" Access Policies are enabled for Everyone.
Comment 2 Dan Callaghan 2014-05-20 07:33:49 UTC
The Reserve Workflow has always deliberately excluded Prototype systems. I think the intention was to avoid offering casual users a system which might not actually work properly. It might be reasonable to show Prototype systems in the Reserve Workflow, provided we can give people sufficient warning that the system they are picking is a prototype and might have problems. We would probably want to be able to show the system notes, or some other description of what the system actually is and what might be wrong with it (for example, "sometimes hangs on bootup, needs to be reset until it boots successfully"). If the prototype systems in question are actually reliable and work properly, they should just be changed to Machine rather than Prototype.
Comment 3 Dan Callaghan 2014-05-20 07:34:54 UTC
Another problem is that we have never actually documented anywhere what "Prototype" means or why a system might be set to Prototype instead of Machine.
Comment 4 Nick Coghlan 2014-05-28 05:39:17 UTC
Wouldn't it make more sense to just deprecate Prototype and instead say "use a more restrictive ACL with the system in Manual mode?" * putting it in Manual mode will keep it away from the scheduler (unless you choose it specifically via the new force option in 0.17+) * limiting reserve access will keep the availability restricted to folks that already know it is a prototype system That is, given the ACL changes and the upcoming change to Manual mode handling, will there still be a meaningful use case for having "Prototype" as a separate type?
Comment 5 Dan Callaghan 2016-10-25 07:55:55 UTC
http://gerrit.beaker-project.org/5359 It's worth distinguishing between the two different behaviours of the Reserve Workflow... If you go to Reserve Workflow and say "pick any system" then Beaker *won't* give you a Prototype system -- that is the existing behaviour we have now. But if you go to Reserve Workflow and say "pick a specific system" then with this patch, Beaker will include Prototype systems in the list and you can pick them, assuming that you have the necessary permissions. Presumably if a Prototype system is actually dodgy in some way, it will have a locked down access policy, and so anyone who sees it offered will hopefully recognise that it's a prototype and only pick it if they know how to deal with its problems.
Comment 8 Dan Callaghan 2017-02-21 18:50:05 UTC
Beaker 24.0 has been released.