Pre-defined access policies vs. system pools?
Dan Callaghan <dcallagh <at> redhat.com>
2015-01-12 07:24:16 GMT
In Beaker 20 we are planning to implement "pre-defined access policies",
the last remaining piece of the original access policies design
I remember when we were writing that proposal and the system pools one,
we went back and forth quite a lot before settling on that approach. We
came to realise that separating the pre-defined access policies entirely
from system groups/pools made things simpler.
However I am still worried that creating a new namespace for system
access policies is not a good idea. It means essentially turning access
policies into a first-class object in Beaker, which means we will
eventually have to provide a way to list and search and describe and
delete them. Plus it adds yet another potential for namespace conflicts:
what happens when someone creates a pre-defined access policy named "lab
I am wondering if we should instead implement the bare minimum of system
pools, and then use that as the basis for pre-defined access policies?
The choice of access policy for a system will then be either "custom
access policy" (what we have now) or "inherit access policy from:
Existing system groups would be converted into pools by a database
migration. It would create a same-named pool for every system group,
with the pool's owning group set to the same-named group. We would
implement the UI for creating pools and adding/removing systems, but the