[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