summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNick Coghlan <ncoghlan@redhat.com>2013-03-06 17:15:04 +1000
committerNick Coghlan <ncoghlan@redhat.com>2013-03-06 17:20:27 +1000
commit98a0014b058272c542dea5a4387a458c5ce70c82 (patch)
tree6d938bb60679d379f3eaa15ef5babd7e10a9fad8
parent54abb0643865a064af66b37aa2b56c6af4f0a0b0 (diff)
Updates to Enhanced User groups design proposal
- separated out "Modify Jobs" as a distinct per-member permission - made it clear that this builds on the existing groups support - made it clear that LDAP groups do NOT allow per-member settings - added UI sketches for updating group details - group-manage command renamed to group-modify - group description field added - data migration guide added for existing Beaker installations Change-Id: I29e93329d94b56a196b00e511391b85d41ec90ee
-rw-r--r--dev/proposals/enhanced-user-groups.rst211
1 files changed, 175 insertions, 36 deletions
diff --git a/dev/proposals/enhanced-user-groups.rst b/dev/proposals/enhanced-user-groups.rst
index 47475d3..177bca6 100644
--- a/dev/proposals/enhanced-user-groups.rst
+++ b/dev/proposals/enhanced-user-groups.rst
@@ -3,8 +3,8 @@
Enhanced User Groups
====================
-:Author: Dan Callaghan
-:Editors: Nick Coghlan, Raymond Mancy
+:Authors: Dan Callaghan, Nick Coghlan
+:Editors: Raymond Mancy
:Target Release: 1.0
@@ -28,8 +28,9 @@ Proposal
Under Beaker's current group design, all group management is carried out
by Beaker administrators, and groups can own systems, but not jobs.
-This proposal enhances the capabilities of the group model by:
+This proposal enhances the capabilities of the existing group model by:
+* adding a group Description field in addition to the existing Display Name
* allowing users to manage their own groups, rather than requiring
administrator involvement
* allowing administrators to create groups that are automatically derived
@@ -39,11 +40,66 @@ This proposal enhances the capabilities of the group model by:
A Beaker user can be in zero or more groups, and any Beaker user may
create a new group at any time.
-On each group, the only permission that can be granted is "group ownership".
+All members of a group are able to submit jobs on behalf of that group.
+Group members may also be granted the following additional permissions
+on a group:
-Detailed Use Cases
-------------------
+* group ownership
+* group job modification
+
+
+Group ownership
+~~~~~~~~~~~~~~~
+
+Group ownership permissions grant a user the ability to:
+
+* add and remove group members
+* grant and revoke group ownership permissions
+* grant and revoke job modification permissions
+* update the group's display name
+* update the group's description
+
+As a group may have multiple owners, "group ownership" may sometimes
+be referred to as "group co-ownership".
+
+
+Job modification
+~~~~~~~~~~~~~~~~
+
+When a job is submitted on behalf of a group, any members of that group
+with job modification permissions will have the same level of access to
+and control over the job as the original submitter.
+
+By default, new members added to a group are granted job modification
+permissions. This will be configurable on a per-user basis, allowing the
+addition of automated service accounts which can submit jobs on behalf
+of the group, but have no additional access to jobs that are not
+submitted through the automated service.
+
+
+General Use Cases
+-----------------
+
+The primary use case for the additional features is to simply improve the
+scalability of Beaker usage in large organisations, by:
+
+* removing the installation administrators as a bottleneck for group updates.
+* making it possible to derive group membership directly from an LDAP
+ server.
+* allowing a team of submitters to share responsibility for a set of jobs,
+ rather than limiting access to the specific user that carried out the
+ actual submission.
+
+In addition, this update aims to make it easy for users to set up automated
+systems that submit jobs on their behalf by creating personal groups and
+granting the ability to submit jobs on their behalf to the account used
+for the automated service, *without* needing to give the automated service
+permission to modify their jobs after submission.
+
+
+Proposed User Interface
+-----------------------
Self-Service User Groups
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -53,11 +109,11 @@ Self-Service User Groups
Through the web UI:
Select "Hello -> My Groups" from the menu, then click "Create". Enter
- a group name and display name and click "Create".
+ a group name, display name and description and click "Create".
Through the ``bkr`` cli::
- bkr group-create --display-name="My New Group" <mynewgroup>
+ bkr group-create --display-name="My New Group" --description="This is my very own group. Email me@example.com if you want to be included." <mynewgroup>
A new group is created, with one member (you) who is also the group owner.
The change is recorded in the "Group Activity" log.
@@ -79,7 +135,11 @@ A new group is created, whose membership is populated from the LDAP
directory configured in your Beaker installation. An admin can refresh the
group from LDAP by running ``beaker-ldap-refresh --group=<groupname>``
on the server. Beaker will ship with a cron job to refresh all LDAP groups
-once per day.
+once per day, but the administrators of a particular installation may
+choose to refresh the group membership more frequently.
+
+Note that LDAP groups cannot be updated through Beaker. They have no
+owners, and all members are treated as having job modification permissions.
* I want to view the details of a group of which I am a member. (BZ#541282)
@@ -92,6 +152,23 @@ Through the ``bkr`` cli::
bkr group-members <mygroup>
+* I want to update the details of a group I own.
+
+Through the web UI:
+
+ Select "Hello -> My Groups" from the menu, then click the name of the
+ group you are interested in to go to its group page.
+
+ To update the display name and/or description for the group, click
+ "Edit Group", update the group details, then click "Save Changes".
+
+Through the ``bkr`` cli::
+
+ bkr group-modify --display-name="My Group" --description="This group is mine. Email me@example.com if you want to be included." <mynewgroup>
+
+The group details are updated and the change is recorded in the
+"Group Activity" log.
+
* I want to add other users to a group I own. (BZ#908176)
Through the web UI:
@@ -101,12 +178,13 @@ Through the web UI:
Through the ``bkr`` cli::
- bkr group-manage --add-member=<someusername> <mygroup>
+ bkr group-modify --add-member=<someusername> <mygroup>
The user is added to the group. The change is recorded in the
"Group Activity" log.
-* I want to grant/revoke another member owner rights to the group. (BZ#908174)
+* I want to grant another member owner rights to the group (or revoke
+ those rights). (BZ#908174)
Through the web UI:
@@ -115,12 +193,30 @@ Through the web UI:
Through the ``bkr`` cli::
- bkr group-manage --grant-owner=<someusername> <mygroup>
- bkr group-manage --revoke-owner=<someusername> <mygroup>
+ bkr group-modify --grant-owner=<someusername> <mygroup>
+ bkr group-modify --revoke-owner=<someusername> <mygroup>
The user is granted owner rights, making them a co-owner of the group.
The change is recorded in the "Group Activity" log.
+* I want to grant another member job modification rights for the group (or
+ revoke those rights).
+
+Through the web UI:
+
+ Go to the group page. Find the other user in the membership list,
+ check/uncheck the checkbox in the "Modify Jobs" column, then click
+ "Save".
+
+Through the ``bkr`` cli::
+
+ bkr group-modify --grant-modify-jobs=<someusername> <mygroup>
+ bkr group-modify --revoke-modify-jobs=<someusername> <mygroup>
+
+The user is granted job modification rights, allowing them to modify jobs
+submitted on behalf of the group as if they were the job submitter.
+The change is recorded in the "Group Activity" log.
+
* I want to remove a member from a group I own. (BZ#908178)
Through the web UI:
@@ -129,7 +225,7 @@ Through the web UI:
Through the ``bkr`` cli::
- bkr group-manage --remove-member=<someusername> <mygroup>
+ bkr group-modify --remove-member=<someusername> <mygroup>
The user is removed from the group. The change is recorded in the
"Group Activity" log.
@@ -152,19 +248,21 @@ Through the ``bkr`` cli::
The job will be owned by that group and the user that submitted the job.
There can be only one "job-group" per job, thus multiple groups having ownership
-of a single job is not possible. All members of the group will be able to
-ack/nack, change priority, edit whiteboard, and change retention tag. The root
-password used in the job will be the group root password (if one is set),
-otherwise it will be the root password set in the preferences of the submitting
-user. The public SSH keys of all group members will be added
-to /root/.ssh/authorized_keys.
+of a single job is not possible. All members of the group with job modification
+permissions will be able to ack/nack, change priority, edit whiteboard, and
+change retention tag. The root password used in the job will be the group
+root password (if one is set), otherwise it will be the root password set in
+the preferences of the submitting user. The public SSH keys of all group
+members with job modification permissions will be added to
+``/root/.ssh/authorized_keys``.
* I want to view a list of jobs for all groups of which I am a member.
(BZ#908185)
The default filter for the "My Jobs" page will include all jobs the user
can manage, including those the user submitted themselves, as well as
-those submitted on behalf of a group of which the user is a member.
+those submitted on behalf of a group where the user has job modification
+permissions.
* I want to view a list jobs for a particular group (of which I am a member).
@@ -174,12 +272,45 @@ particular groups (whether they are a member of those groups or not), as
well as displaying only the jobs that were not submitted on behalf of a
group at all.
-* I want to set the shared root password to be used in all jobs for a particular group. (BZ#908186)
+* I want to set the shared root password to be used in all jobs for a
+ particular group. (BZ#908186)
+
+Through the web UI:
+
+ Go to the group page. Enter the root password in the "Root Password" field
+ and click "Save". The root password may be given in hashed form (suitable
+ for inclusion in ``/etc/shadow``) or in the clear.
+
+Through the ``bkr`` cli::
+
+ bkr group-modify --root-password=<thevalue>
+
+The given root password will be used when provisioning jobs for this group.
+It will be visible on the group page to other members of the group. If the
+password is given in the clear Beaker will *not* automatically hash it
+before storing, to make it easier to share amongst the group (This
+behaviour deliberately differs from that for individual root passwords set
+on the Preferences page - when given in the clear, individual passwords are
+automatically hashed before storage).
+
+Changes to the group's root password are recorded in the "Group Activity"
+log. Th activity log only records when the change occurred, and the user
+that made the change - the password itself is not recorded in the activity
+log, not even in hashed form).
-Go to the group page. Enter the root password in the "Root Password" field and click "Save". The root password may be given in hashed form (suitable for /etc/shadow) or in the clear.
-Or: bkr group-manage --root-password=<thevalue>
-The given root password will be used when provisioning jobs for this group. It will be visible on the group page to other members of the group. If the password is given in the clear Beaker will *not* automatically hash it before storing, to make it easier to share amongst the group. (This behaviour differs from that for individual root passwords set on the Preferences page - when given in the clear, individual passwords are automatically hashed before storage) Changes to the group's root password are recorded in the "Group Activity" log (this only records when the change occurred, and the user that made the change - the password itself is not recorded in the activity log, even in hashed form).
+Upgrading Existing Beaker Installations
+---------------------------------------
+
+All members of existing groups in a Beaker installation will be granted
+job modifications permissions for each group where they are a member.
+
+This means that groups that already existed in a Beaker installations will
+not have any designated owners after the installation is upgraded. After
+upgrading, users and administrators of the Beaker installation will
+need to coordinate the initial allocation of ownership privileges to
+members of existing groups, as well as deciding which groups can be deleted
+and replaced with LDAP group references.
Deferred Features
@@ -199,33 +330,41 @@ design:
The draft web UI design is the same as that for managing group members, but
using the "Sub-group" list instead of the "Members" list. For the CLI::
- bkr group-manage --add-subgroup=<groupname> <mygroup>
- bkr group-manage --remove-subgroup=<groupname> <mygroup>
- bkr group-manage --grant-owner-subgroup=<groupname> <mygroup>
- bkr group-manage --revoke-owner-subgroup=<groupname> <mygroup>
+ bkr group-modify --add-subgroup=<groupname> <mygroup>
+ bkr group-modify --remove-subgroup=<groupname> <mygroup>
+ bkr group-modify --grant-owner-subgroup=<groupname> <mygroup>
+ bkr group-modify --revoke-owner-subgroup=<groupname> <mygroup>
+ bkr group-modify --grant-modify-jobs-subgroup=<groupname> <mygroup>
+ bkr group-modify --revoke-modify-jobs-subgroup=<groupname> <mygroup>
Beaker will not permit a group to be a member of another group if it forms
a cycle.
+ This feature will also make it possible to have an LDAP-defined group as
+ part of a group that also allows manual addition of members through
+ Beaker.
+
.. _Closure Table: http://stackoverflow.com/questions/192220/what-is-the-most-efficient-elegant-way-to-parse-a-flat-table-into-a-tree/192462#192462
* User-level self service to request group membership, or to remove yourself
from groups. This capability is likely to be added in a later iteration.
+ In the meantime, group owners may include information on requesting
+ membership in the group description, and the list of group owners will
+ be visible in the web UI.
-* More fine-grained group permissions. The initial iteration has only two
- levels of access, ordinary group members and group (co-)owners. It may be
- desirable to separate out the following four explicit permissions in a
- future release:
+* More fine-grained group permissions. The initial iteration has only three
+ effective levels of access, job submission accounts, ordinary group members
+ and group (co-)owners. It may be desirable to separate out the last level
+ further in a future release:
* Add/remove members (currently allowed for all co-owners)
* Grant/revoke co-ownership (currently allowed for all co-owners)
- * Submit jobs on behalf of the group (currently allowed for all members)
- * Manage jobs on behalf of the group (currently allowed for all members)
+ * Modify group display name and description (currently allowed for all co-owners)
* Group deletion. The initial iteration does not allow groups to be deleted,
or even hidden. If subgroup management is added, and the associated UI
includes some form of list for group selection, then it is likely that
group owners will be granted the ability to mark a group as *hidden*, so
- it doesn't show up in such lists. Creating a useful UI for the
+ it doesn't show up in such lists. Creating a usable UI for the
:ref:`proposal-system-pools` proposal may also lead to this feature
being implemented.