Currently, the "System Pools" and "Implicit System Pools" design
proposals are structured such that the pools are initially made
explicit, and then we add a separate mechanism to implicitly associated
them with users and groups.
I'd like to propose that we instead consider approach this differently,
and do the *implicit* pools first, using them as a back end
implementation technique for existing Beaker concepts, and then expand
them to additional use cases over time.
With this revised approach, the first increment of the functionality
would look at implicitly associating a system pool with every user. When
a user is the "owner" for a system, then that system is considered part
of their implicitly associated pool
The advantage of this approach is that it allows us to adopt the pool
model for system permissions handling, *without* needing to immediately
introduce new UI concepts for explicit management of the pools. Instead,
users would merely gain the ability to set usage policy for systems they
The second increment of the functionality would then expand the implicit
pool concept to user groups. Associating a system with a group would
then make the system part of that group's pool in addition to being part
of the owner's pool. This increment would need to address some of the
thornier permissions questions that arise when a system is part of two
pools (at the least the owner's pool and the group's pool, but
potentially also pools for other groups as well).
Finally, we will be able to expand the pool functionality to permit the
creation of explicit system groups, separate from the implicit groups,
in order to set special permissions for those systems (or just to ensure
they aren't used accidentally).
This seems like a more natural evolution from the existing capabilities
of Beaker to where we want to get to.
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/