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.