1801118 - add members to web-services-developers team in mozilla-sre-deploy

Status: RESOLVED DUPLICATE of bug 1800778

(mozilla.org :: Github: Administration, task)

Description

[André Honeiser]

Hello,

please add the following people to the web-services-developers team in the mozilla-sre-deploy org:

akatsoulas
escattone
smithellis

Can we also get more Maintainers into that Team (to allow us to extend the User list on our own in the future)? SRE Teams are managing repos in that org to onboard applications to gcp, makes sense to me to have green-sre / purple-sre / data-sre members in the maintainer role for web-services-developers.

Best,

André

Comment 1

[Chris Knowles [:cknowles]]

Going backwards - Note that adding new members to the org is an owner function - so these three you'd have to file a bug like this - but you can totally add existing members to teams if you're a maintainer. However, "Add some more maintainers" isn't actionable - is there anyone specific you'd nominate? (right now the requester of the team, :wezhou is the only maintainer. I've cc'd them for their weigh in)

If the "waiting for approvals and owners to show up" is causing you concern - in the immediate case any repo admin can add any github user to the repos that they admin - you could add the users to the specific repo that's causing the immediate concern and file this type of bug to make the future easier.

Now for the specific users - they all are already taking github licenses. so I don't need their manager approval for license use. However, per runbooks, I do need the maintainer of the requested team to weigh in if this is a good change. (so I've changed that cc to a needinfo) ... :wezhou, please approve or ask questions, and while you're here, please let me know if there's other maintainers you'd nominate (or you can set them yourself, being maintainer of the team)

Comment 2

[André Honeiser]

Thanks Chris, a bit of background might be useful .. I'm currently onboarding an Application to GCP, the users given are all developers of that app, and need to be able to view deployment processes in GHA, so I've added that web-services-developers group as a "pull" team to the repository in question.

Since we're not using that Org for a single application, there's going to be more requests like this I assume, so to me, it would make sense to have SREs creating deployment repos (which is basically everyone in data-sre / green-sre / purple-sre) able to update this group's member list.

Take the last comment as an improvement idea, managing teams rather than individual identities is always a benefit, I would really strongly like to avoid to add individual people to repositories ..

So, task closed if we can get these 3 users into that developers team, and we should add more maintainers to that team .. Thanks!

Comment 3

[Chris Knowles [:cknowles]]

So, yes, we too agree that managing teams is better than identities. I was merely giving you a "if you need to move faster" option to things.

But since the approval path for adding people to teams for us GHE owners is "if there's a team maintainer they're a better say-so than our guesses" - hence why I'm forced to ask the maintainer of the team for approval. The main concern from what I'm seeing is that adding new members to the org is an owner function, and there's no real way around that - The hope is that as this org matures the need to add people will slow to a trickle, and this sort of bug would become merely a function of onboarding new users.

But I'm going to add secops here, as this path shows a real concern with these repos being private - there's no way to make them open by default, thus requiring the membership or OC dance. (and I'm not sure if internal would work - due to the fact that any contributor in the mozilla org, NDAd or not, could see into them.) Hal/Austin, thoughts?

Comment 4

[hwine]

Clearly, this situation needs to be re-reviewed with the GCP leads -- that will happen over in bug 1800778. Those restrictions were set for security reasons, and this use case either wasn't considered, or is "as designed".

:cknowles - Until that is resolved, please don't make maintainer changes.

:Andre - please work with the repo admin for "outside collaborator" status if you can't wait for the resolution of bug 1800778.

Workaround provided, and no action possible here, so closing.

Comment 5

[André Honeiser]

thanks everyone!

FYI: added users as outside collaborators for now