----- Original Message -----
From: "Dan Callaghan" <dcallagh(a)redhat.com>
To: "beaker-devel" <beaker-devel(a)lists.fedorahosted.org>
Sent: Monday, January 12, 2015 5:24:16 PM
Subject: [Beaker-devel] Pre-defined access policies vs. system pools?
In Beaker 20 we are planning to implement "pre-defined access
policies",
the last remaining piece of the original access policies design
proposal:
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
systems"?
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:
<pool>".
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
If I understand properly, a system would be in multiple system pools. So how do we decide
which
system pool's access policies would be used in the system? I think it may be working
by setting
proprieties on system pools.
Cheers, Matt Jia