Page MenuHomePhabricator

Document and update Gerrit groups for repositories related to Toolforge
Closed, InvalidPublic

Description

I'm a member of the Gerrit groups labs-toollabs ("Tool Labs administrators", https://gerrit.wikimedia.org/r/#/admin/groups/461, with @Andrew and @coren and all of SRE) and toollabs-trusted ("Users trusted to +2 software changes for toollabs related software.", https://gerrit.wikimedia.org/r/#/admin/groups/967, with @Andrew, @bd808, @chasemp, @Legoktm, @valhallasw and @yuvipanda) and until now I wasn't really aware of that :-).

We have four Gerrit repositories that are exclusive to Toolforge:

  • labs/toollabs:
[access "refs/*"]
	owner = group Project and Group Creators
	owner = group labs-toollabs
	owner = group toollabs-trusted
	read = group Anonymous Users
	rebase = group Registered Users
	submit = group JenkinsBot
	submit = group Project and Group Creators
	submit = group labs-toollabs
	submit = group toollabs-trusted
  • operations/docker-images/toollabs-images:
[access "refs/*"]
	owner = group Project and Group Creators
	owner = group toollabs-trusted
	submit = group JenkinsBot
	submit = group toollabs-trusted
  • operations/software/tools-manifest:
[access "refs/*"]
	owner = group Project and Group Creators
	owner = group toollabs-trusted
	submit = group JenkinsBot
  • operations/software/tools-webservice:
[access "refs/*"]
	owner = group Project and Group Creators
	owner = group toollabs-trusted
	submit = group JenkinsBot

IMHO we should merge toollabs-trusted into labs-toollabs (and make @Legoktm an honorary Toolforge administrator) and amend all access rights to only refer to labs-toollabs (or rename that group to toollabs-admins or something like that) to reduce the levels of administratorness – if you're root on Toolforge, you should have +2 on repositories exclusive to Toolforge. To further reduce redundancy it would be nice to not have to list the administrators individually, but refer to the members of the tools.admin group (typing ldap/tools.admin under "Included Groups" and clicking "Add" does nothing unfortunately).

Afterwards it should be documented that new Toolforge administrators who are not a member of SRE need to be added to that Gerrit group as well (and I think there is also no documentation that they need to be added to the tools.admin service group and the roots sudo policy).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The labs-toollabs group looks to be the default group that was created along with the labs/toollabs repository. Since the more general toollabs-trusted group is already granted owner rights on labs/toollabs I think we can drop it from out Toolforge root onboarding checklist now.

We will need help from a gerrit admin to actually remove the group, but I think that is a good idea to reduce confusion in the future about the purpose of the labs-toollabs group.

Just to clarify, you want to drop the labs-toollabs group and retain toollabs-trusted correct?

To further reduce redundancy it would be nice to not have to list the administrators individually, but refer to the members of the tools.admin group (typing ldap/tools.admin under "Included Groups" and clicking "Add" does nothing unfortunately).

My (limited) understanding is that tools.admin is a servicegroup in LDAP, not a normal group, which might be what Gerrit needs. I'm not sure what the distinction actually is though.

• bd808 renamed this task from Document and update Gerrit groups for repositories related to Tool Labs to Document and update Gerrit groups for repositories related to Toolforge.Jul 15 2020, 10:41 PM
• bd808 raised the priority of this task from Medium to Needs Triage.
• bd808 added a subscriber: yuvipanda.
dcaro subscribed.

We have moved most of the toolforge repos to gitlab :), we should move the rest too, I think there's no reason to keep them separated (and user access control is easier in gitlab).