Page MenuHomePhabricator

Retire /cloudvps-repos, merge to /repos
Open, Needs TriagePublic

Description

I'm not seeing a point in the separate /cloudvps-repos hierarchy. Can we just merge that to /repos to uncomplicate the structure a bit?

Unlike /toolforge-repos we have no automation create things there, and those with Cloud VPS access can already access the same things that runners hosted there can so I'm not seeing any security reasons to keep those separate either.

Event Timeline

brennen added subscribers: • bd808, brennen.

I can't really think of any objections to this, other than maybe it's a useful bucket. @bd808, does anything come to mind for you? I think T305301: GitLab: separate trees for WMCS infrastructure and tenants is where cloudvps-repos came from originally.

Would we want an equivalent repos/cloudvps instead? (Edit: I assume yes, given everything else is in a repose/foo group.)

Would we want an equivalent repos/cloudvps instead? (Edit: I assume yes, given everything else is in a repose/foo group.)

I don't think so, the current grouping seems mostly be for groups of people working on things and not where they are hosted. (Otherwise I'd argue that this repo should be in /repos/ovh, this one in /repos/digitalocean and this one in /repos/taavis-homelab.)

@bd808, does anything come to mind for you?

As I recall we were still thinking about things in the T305301: GitLab: separate trees for WMCS infrastructure and tenants era from a very hierarchical repo layout point of view similar to the Gerrit hierarchy.

I do think having the /toolforge-repos bucket makes sense both from the automation side and for helping discover code for Toolforge tools. It could have been just as easily been named /repos/toolforge-tools or something too. The main point is one top level to grouping. I don't have any really strong feelings about grouping and discovery one way or another for the /cloudvps-repos bucket today. https://gitlab.wikimedia.org/cloudvps-repos/deployment-prep for instance could just as easily in my mind be https://gitlab.wikimedia.org/repos/beta-cluster or nested under some other relevant group.

I do think having the /toolforge-repos bucket makes sense both from the automation side and for helping discover code for Toolforge tools. It could have been just as easily been named /repos/toolforge-tools or something too.

I think the main (only?) thing offered by having the toolforge bucket outside the /repos tree is making a distinction in runner access.

At any rate, it seems like there are no objections to retiring the cloudvps-repos bucket. Let me know if there's anything there I can help with.

This separation was actually kind of nice for (sourcebot) codesearch. We could configure separately "all prod repos" vs "all cloud repos" with a simple config line. Because we have to specifiy all of the "roots" to index.

We could configure separately "all prod repos" vs "all cloud repos" with a simple config line. Because we have to specifiy all of the "roots" to index.

That simplification was an oversimplification as repos like https://gitlab.wikimedia.org/repos/userscripts/zvpunry_userscripts and https://gitlab.wikimedia.org/repos/wikisp/wikisp-comcombot are very likely not what you meant by "prod repos".

ACK. My comment doesn't mean I have a serious concern if this is being done. That being said also not sure if there was a real problem we are fixing.