Description of problem:

If a person uses beaker for automated testing, and they have 100 tests they normally submit to the general population of machines, then they happen to write a test that requires access to a restricted group, and they are then added to a user group in order to grant them access to those restricted machines, now all 100 of their tests will happily use the restricted machines even if only the one new one is the only one that actually needs those restricted machines.  The user must now modify their original 100 scripts to exclude the restricted group if they do not wish their general tests to use the restricted group.  This is obviously a pain point.  As a concrete example, the "RDMA Machines in Westford Cluster" group contains all of the machines in the Westford RDMA cluster, and those can be used for RDMA testing.  It is a total waste of RDMA resources to use them to run a desktop test of Evolution.  Therefore, we want anyone we add as a member of rdma-users (which grants reservation privileges to the RDMA cluster) to only submit RDMA related jobs to the cluster.

However, there are imaginable scenarios where the exact opposite is true.  For instance, let's say you have a 100 machine pool (possibly these machines have no pool at all, or they are part of a general use pool), and then you have people that are members of the user group "VIPs" that are supposed to get access to a 50 machine pool of restricted access machines intended to allow them priority in getting their jobs completed.  You want the VIPs to pull from both the VIP pool and the general pool so their jobs complete ASAP, while the non-VIPs take their turn in line only in the general pool.  In this case, you don't want anyone to modify their jobs, you simply want membership in the VIPs user group to expand the available machines for the user's jobs to include the VIPs pool.

Suggested Change:

Add a property to the access control elements of pools/machines in beaker.  The current list of ACLs looks like this:

View
View power settings
Edit this policy
Edit system details
Loan to anyone
Loan to self
Control power
Reserve

I suggest changing the Reserve ACL into a tri-state option:

None <- No reservation privileges
Reserve Explicitly <- Only reserve if the job explicitly calls out this machine/pool
Reserve Generally <- Allow a job that doesn't call out this machine/pool to reserve this machine

So, in the two situations above, the RDMA cluster would use Reserve Explicitly so that a user would have to call out the RDMA cluster in the jobs that they want to hit the cluster, and any job that doesn't would go to the normal pools, while the VIPs pool would use Reserve Generally so that a VIPs job would possibly land in the VIPs pool without being explicitly called out.

Or leaving the Reserve permission as is, and adding a new option: Require Explicit Request so that if a user/group has reservation permission to a machine/pool, the admin can set/clear the Requires Explicit Request (I really only suggest this if its significantly easier to add a new flag and migrate existing installations to use it than it is to change a flag to a tristate and migrate existing installations to use it during an upgrade).

An alternative method of achieving the same goal would be to add an additional machine state to each machine.  Instead of Broken, Manual, Automated, you could have Broken, Manual, Automated, Restricted where Restricted is basically Automated but with explicit call out of the machine/pool required.  Personally, I prefer the ACL approach because then when you have 100 machines that are members of a pool or various pools, you can set the ACL on the pool(s) and leave the machines set to pull their ACL from the Pool ACL and update them all at once.