----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
Sent: Tuesday, February 10, 2015 12:33:47 PM
Subject: Re: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
On 02/09/2015 10:37 AM, Amit Saha wrote:
> So, here is a sample use case:
> You create a system pool and define a "pool policy". Now any system in
> (both outside and inside the system pool) can be access controlled by this
> pool policy
> or by its own custom policy.
Ah, so the intent is to allow use of the pool policy without being a
member of the pool?
While I like that as a general notion, we may need to consider the UX
implications. One possibility might be to segment the pool selection
list so pools the system is part of appear first.
That's a good idea. Considering that there will potentially be a large number of
pools and will only increase with time, presenting the ones which the system
is a member of first may be a good idea.
Alternatively, we might wish to restrict the UX in the initial
implementation to only allowing a choice from pools the system is a part
of, rather than all pools. I think that's going to be easier to explain
in the documentation, rather than decoupling the two decisions and
having to explain that pool membership and pool policy inheritance are
actually unrelated. I'm a fan of this approach, as I'm struggling to
think of a good use case (or, indeed, *any* use case) for making the
two decisions completely independent.
For the use case that a pool owner creates a pool, adds systems to it and wants to use
the same pool policy across systems - your suggestion is perfect. What if I want to
make use of a random pool's access policy because I just happen to find my
identical but I do not/cannot add my system to the pool?
If we later get an *RFE* to allow use of pool policies for systems that
aren't members of that pool, we could consider it based on a concrete
use case rather than speculation.
That's what I just did above .. :-)
SED, Hosted & Shared Services
Red Hat, Inc.