----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)lists.fedorahosted.org
Sent: Monday, February 16, 2015 6:30:53 PM
Subject: Re: [Beaker-devel] Design proposal: Predefined Access Policies for Systems
On 02/16/2015 06:09 PM, Amit Saha wrote:
>> From: "Nick Coghlan" <ncoghlan(a)redhat.com>
>> 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
> requirements are
> identical but I do not/cannot add my system to the pool?
Then I'd tell you that's a bad idea because you have no idea how that
pool's policy is going to evolve in the future. It may meet your needs
today, but what about tomorrow? Next week? Next year?
Allowing a system owner to use a pool policy without their system being
part of the relevant pool now strikes me as a genuinely *bad* idea,
since it creates a dependency without a mutual agreement between the two
parties, so the pool owner may change their ACLs without even
considering the possible implications for systems outside the pool that
may be using that ACL.
By contrast, if systems can only be assigned policies from pools they're
members of, then you have a bidirectional agreement:
* someone with management rights on the pool adds the system
* someone with management rights on the system chooses that pool's policy
Indeed. This is the right way to go about it. I have updated the design proposal:
http://gerrit.beaker-project.org/#/c/3989/
It also adds the pool ownership modification use case and possible interfaces.
Best,
Amit.
--
Amit Saha
SED, Hosted & Shared Services
Red Hat, Inc.