Any capacity or isolation concern with git-over-HTTPS traffic on text-lb?

No direct concerns but I have two things for consideration:

• We generally tend to keep text-lb strictly for text but of course that ship has long sailed anyway. What we try to do is not introduce new things that may affect text-lb and its primary purpose, so that's something to keep in mind. (And yes, in that case you don't need a separate service entry, just the Varnish and ATS configs for the backend.)

• We should be cautious of timeouts here -- I presume that in some cases we will have long-lived HTTP requests for some of the repositories? That, like the Gerrit thing, is something to be mindful about.

Adding @BBlack for his input.

Well, for this and other similar use-cases, I'd clarify that while technically it is cache_text servicing the requests, it's really cache_misc which happens to be a sub-unit of VCL within cache_text today. We should still eventually re-separate these clusters physically for a whole host of reasons.

Long timeouts and very bulky transfers are definitely a concern, so long as cache_misc continues to be part of cache_text. If they're rare it probably won't be an issue in practice. Some thought should be put into looking at the edge cases, though: what's the biggest repo in gitlab? How long does it take to clone that on some exacmple connection types?

In T428903#12014938, @BBlack wrote:

what's the biggest repo in gitlab?

I think I can answer this one. It's 98.8 GB for Thcipriani / Flaky Tests.

The top ten are by size, in GB

98.8
39.0
27.6
16.1
13.8
13.2
12.3
12.2
12.1
9.1

In T428903#12014938, @BBlack wrote:

Well, for this and other similar use-cases, I'd clarify that while technically it is cache_text servicing the requests, it's really cache_misc which happens to be a sub-unit of VCL within cache_text today. We should still eventually re-separate these clusters physically for a whole host of reasons.

Yes thanks for clarifying that, and yeah, we should certainly make progress on those...

Long timeouts and very bulky transfers are definitely a concern, so long as cache_misc continues to be part of cache_text. If they're rare it probably won't be an issue in practice. Some thought should be put into looking at the edge cases, though: what's the biggest repo in gitlab? How long does it take to clone that on some exacmple connection types?

While we get clarity on that, note that one possible path forward is that we set and tune this on a per-map basis, so essentially:

params:
  - '@plugin=/usr/lib/trafficserver/modules/conf_remap.so'
  - '@pparam=proxy.config.http.transaction_no_activity_timeout_out=16'
  - '@pparam=proxy.config.http.transaction_active_timeout_out=16'

Thanks @Dzahn @ssingh @BBlack for these answers, using cache_misc will greatly simplify things.

I've amended 1290731 with a tuning proposition to allow cloning large repositories.

params:
  - '@plugin=/usr/lib/trafficserver/modules/conf_remap.so'
  - '@pparam=proxy.config.http.transaction_no_activity_timeout_out=300'
  - '@pparam=proxy.config.http.transaction_no_activity_timeout_in=300'
  - '@pparam=proxy.config.http.transaction_active_timeout_out=3600'
  - '@pparam=proxy.config.http.transaction_active_timeout_in=3600'

Parameters are inspired from profile::trafficserver::backend::http_settings for cache hosts, with an additional time for no activity to leave some time for Gitaly to generate packfiles.

I think we could also recommend using SSH for these.

Maybe let me also ask @thcipriani if 98.8 GB Thcipriani / Flaky Tests is expected, needed and growing, given how the second largest is less than half the size.

In T428903#12020525, @Dzahn wrote:

Maybe let me also ask Tyler if 98.8 GB Thcipriani / Flaky Tests is expected, needed and growing, given how the second largest is less than half the size.

@Jelto asked me about that repo long ago. I actually rewrote history on that repo to remove large files and force pushed. Current local repo size is 500MB. GitLab never reclaimed that space, though, it seems. (edit for clarity) Delete the lfs storage for that repo if it's possible to do so. It's inaccessible from the repo itself.

Oh, interesting. Thanks for the explanation @thcipriani. Yea, I was only looking at actual file system. So GitLab has not reclaimed the space.

edit: I have to correct myself. This was not by file system but by GitLabs own admin web UI and sorting by storage_size here:

https://gitlab.wikimedia.org/admin/projects/?sort=storage_size_desc

I ran this trying to fix it:

[gitlab1004:~] $ sudo gitlab-rake gitlab:cleanup:orphan_lfs_files PROJECT_PATH="thcipriani/flaky-tests"
I, [2026-06-15T17:17:20.263913 #2917681]  INFO -- : Removed unreferenced LFS files: 0

Let me continue elsewhere to not pollute this general ticket with the details.

In T428903#12020551, @Dzahn wrote:

Oh, interesting. Thanks for the explanation @thcipriani. Yea, I was only looking at actual file system. So GitLab has not reclaimed the space.

Looked up the steps on: https://docs.gitlab.com/user/project/repository/repository_size/#clean-up-repository

1. git filter-repo to remove large file references
2. Upload the commit-map and run Repository Cleanup under Settings for the repo.

I did the git filter-repo back in Oct 2025. But never uploaded the commit-map and ran repo cleanup. I still have the commit-map so I just uploaded it and ran Start cleanup. Maybe that'll get rid of the LFS files. The docs say git objects will be held for two weeks, but given this is LFS storage, not git objects, it's unclear.

Email just now:

Repository cleanup succeeded on https://gitlab.wikimedia.org/thcipriani/flaky-tests

Repository size is now 0.3 MiB