[Beaker-devel] Revised Enhanced User Group proposal on Gerrit

Jan Stancek jstancek at redhat.com
Tue Apr 30 11:55:05 UTC 2013





----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: "beaker-devel" <beaker-devel at 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-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
> 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
> 


More information about the Beaker-devel mailing list