Page MenuHomePhabricator

GitLab: separate trees for WMCS infrastructure and tenants
Closed, ResolvedPublic

Description

Hello!

We (WMCS admins) talked a bit about GitLab migration and agreed that unlike the current setup on Gerrit, we do not want to mix the repositories for WMCS infrastructure maintained by us (examples: Toolforge kubernetes components, PAWS, cloud/instance-puppet) with repositories for any projects hosted on WMCS (examples: toolforge tools such as train-blockers, LibUp).

I believe the easiest way to achieve this would be to create new top-level /repos groups such as /repos/cloudvps-projects and /repos/toolforge-tools to house repositories for WMCS hosted projects and keep the current /repos/cloud for infrastructure only.

Event Timeline

@bd808 and I discussed naming for toolforge tools on GitLab not that long ago, in the context of T191182: Migrate active repositories in Phabricator Differential to GitLab

From my notes there:

  • Names:
    • /repos/cloud/tools/[projectname] ?????
    • Problem: Granting access to the same runners as /repos might a bad idea since anyone can spin up a tool, so this should be a different level of trust.
    • /toolforge/[projectname] or something is probably the easiest solution to this, give them access to the very-untrusted runners

So I think something like a top-level /toolforge makes sense.

Before I do that, two questions:

  • Is there a similar trust issue with cloudvps projects?
  • Is there a reason to define a top-level namespace akin to /repos for this class of thing?

I was thinking since other teams in WMF use team names (/releng, /sre etc) it would match that if WMCS used /wmcs/ for infra projects. Then /cloud/ would be free for user projects running on cloud. My 2 cents.

But if you really want /cloud for infra then I would suggest just /cloudvps for users, rather than cloudvps-projects.