[Beaker-devel] Revised Enhanced User Group proposal on Gerrit
Bill Peck
bpeck at redhat.com
Tue Apr 30 13:07:42 UTC 2013
On 04/30/2013 05:00 AM, Nick Coghlan wrote:
> 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-groups.rst
>
>
> 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
How does this actually work?
The doc you mention above says that all members of the group can
ack/nack, change priority, delete job, etc..
Does this mean that the submit bot user should not be added as a member
of the group? Because if it were a member then it could modify any jobs
submitted under the group.
But if the delegate user is not in the group then what systems will be
used?
I do think this is going in the right direction, just need to make sure
I understand it all. :-)
> 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)
>
> 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.
>
More information about the Beaker-devel
mailing list