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 Beaker (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.
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.
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.
Cheers, Nick.