Bug 1099142 - Scheduler->Reserve fails to list Prototype system even when Access Policies are correctly set
Summary: Scheduler->Reserve fails to list Prototype system even when Access Policies a...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Community
Component: web UI
Version: 0.16
Hardware: All
OS: Linux
unspecified
high vote
Target Milestone: 24.0
Assignee: Dan Callaghan
QA Contact: tools-bugs
URL:
Whiteboard:
Keywords: FutureFeature, Patch
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-19 14:42 UTC by Arthur Benoit
Modified: 2018-02-06 00:41 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-02-21 18:50:05 UTC


Attachments (Terms of Use)

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.


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