One of the pieces of feedback I have received on the System Pools design
proposal is that it seems very confusing and overly complicated to
people that just want the ability to set an "owning group" on a system,
similar to what we're planning for submission of group jobs in 1.0.
So, while I still really like the idea of system pools as an
*implementation* technique, I think the draft proposal needs some
significant UI redesign in order to mostly hide their existence from the
end user.
My current thought is to change the initial proposal as follows (while
keeping the underlying system pool infrastructure):
- system pools will get an "owning group"
- the owning group automatically has all permissions on that pool
- every user group gets a "System Pool" attribute
- these pools are created automatically whenever a new group is created
- the user group is automatically granted all permissions on its own
system pool
- pools for existing groups will be created as part of the 1.1 data
migration
- the underlying naming scheme will be something simple like
"<groupname>-system-pool" (while user groups and system pools are
technically separate name spaces, so we could just reuse the group
names, I expect that would end up being confusing in the long run, since
it would hide the underlying system pool concept *too* much)
- the UI for systems will allow you to set an "owning group". Behind the
scenes, this will add the system to the group system pool.
- the UI for group management will allow you to edit the policy for the
group's system pool
- the UI for group management will allow to get a list of all systems in
the group's system pool
And then explicitly defer the following features:
- providing "Edit pool policy" as a permission on the pool (instead
limit it to the owning group)
- creating pools manually (rather than as part of group creation)
- selecting an existing pool as the group pool when creating a new group
- adding a system to multiple pools
- bulk operations on system pools (script the CLI or XML-RPC API for now)
Thoughts?
Regards,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
_______________________________________________
Beaker-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
