On 02/09/2015 10:37 AM, Amit Saha wrote:
Hi Jeff,
>>
> Amit,
> I read the Link you provided. I do have a question. Is this work
> being done to satisfy additional BZ or other long term goal? Who
> or What it the actual "use case". I see there is a "grey area"
of
> dependency for "Scheduler Integration for System Pools"
Sorry, I don't understand what you mean by "grey area" of dependency.
The main goal of this work is to implement "Predefined Access Policies". The
use case
is to make it possible for multiple systems to share the same access policy without the
same policy needing to be defined separately for all the systems which was first
introduced
in Beaker 0.15 [1].
Upon some discussions (on this mailing list) and thought, we reached the conclusion
that this goal would be best met by introducing the "system pools" feature
which we
had earlier only considered as a standalone change and also included the "Scheduler
Integration for System Pools" change [2].
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.
[1]
https://beaker-project.org/dev/proposals/access-policies-for-systems.html
[2]
https://beaker-project.org/dev/proposals/system-pools.html
I think I see what Jeff's getting at - on the development side, we know
the problem we're aiming to solve with this feature, but that isn't
clear from the design proposal itself. It's missing the clear motivating
use case where we explain what it means from a user perspective.
Something like:
=====================
The original custom access policy feature implemented in Beaker 0.15
presents some usability challenges for shared system management:
* By default, each new system is created with a custom access policy
that merely grants all users the "View" permission. Only the system
owner (which defaults to the user that created the system entry) can
edit the custom access policy or do anything else with the system.
* This is inconvenient for shared system management, as it means each
new system needs to have its ACL configured appropriately for the group
that manages it. Changes to ACLs must also be applied to all systems
covered by that ACL.
* While these activities can be scripted through the remote web API,
there are still plenty of opportunities to get things wrong.
This design proposal addresses that problem by changing the procedure
for configuring a newly added group managed system to be:
* add the new system to the appropriate system pool
* configure the system to use the pool ACL rather than its own custom ACL
The new system will then use the preconfigured pool ACL for access
control, and automatically respect any future changes to that ACL. If
access needs to be temporarily restricted to a select group, then the
system can be switched back to using its custom ACL for a time, before
being returned to using the appropriate pool ACL.
=====================
This description also suggests some potential follow on RFEs (which can
be listed as deferred for now):
- allow a "Notify CC" to be set at the pool level, not just at the
individual system level
- enhancing the "add system" modal to allow specifying a system pool up
front (and configuring the ACL settings accordingly)
- setting or changing the active policy via CSV upload
For that last, we'd also need to ensure that whatever is used to
represent the custom access policy in the CSV can't also be used as a
valid pool name (e.g. "<custom>" or something like that).
As far as the impact on the "System Pools" design proposal, I realised
that the "strict filtering by pool" requirement described there isn't
all that difficult once the core system pools feature is implemented.
It's only the pool *preferences* feature that can't be readily handled
in the current scheduler architecture.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect