----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: "beaker-devel" <beaker-devel(a)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-g...
Key changes:
1. 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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel