----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: "beaker-devel" beaker-devel@lists.fedorahosted.org Sent: Tuesday, 30 April, 2013 11:00:52 AM Subject: [Beaker-devel] Revised Enhanced User Group proposal on Gerrit
Rather than updating the design proposal directly on the site, I decided I wanted some feedback on the current draft first:
http://gerrit.beaker-project.org/#/c/1908/1/dev/proposals/enhanced-user-grou...
Key changes:
- The "job modification" flag on group members is gone, replaced with
the separate concept of a "submission delegate", who can submit jobs on behalf of the group, but cannot modify other group jobs 2. Unlike the previous design, submission delegates retain the ability to modify the jobs they submit. The design we discussed in the other thread (where you could change the actual submitting *user*) has been listed as a deferred feature (because it would require quite a bit more additional UI design work)
Hi Nick,
Is there a field (other than whiteboard), which I could use to distinguish between jobs? For example, say I have group "maintainers" who build packages for RHEL5/6/7. For each package there is a beaker job. How can I make maintainer see only jobs for packages he built?
So, without this "submitting user", how can beaker determine pool of systems, where my job can run? I assume my new ad-hoc group won't be used by any systems other than public ones. Do I need to go over all of my systems and add it? I assume the answer is "for now yes or wait until System Pools proposal is implemented".
Regards, Jan
Another couple of points came up while I was writing it:
- should we allow *completed* single-user jobs to be converted to group
jobs? We originally didn't allow this due to the problem with getting SSH keys installed, but that doesn't apply if the job is already completed, and it may be necessary if we want to eventually remove the existing not-quite-group-jobs behaviour (I don't think we can remove that in 1.0 - we need to allow at least a release for people to migrate to the new tools before we take the old mechanism away).
- LDAP derived groups can't be self-administered in the current design,
but should we at least allow Beaker administrators to nominate submission delegates for them?
Cheers, 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 Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel