Open ulrfa opened 4 years ago
mostynb
commented
4 years ago Making these configurable sounds reasonable. (The other proxy backends have the same settings, it would be good if these could use the same configuration setting instead of duplicating configuration options.)
I'm not so sure about disabling HEAD requests, unless we also disable GET requests. What's the intended use case for this?
Making these modifiable without restarting bazel-remote might be too complex.
ulrfa
commented
4 years ago Thanks Mostyn,
Use case for forwarding GET but not HEAD: If there is a separate cache instance for a remote execution cluster, that should fetch build results also from another central cache instances, but the input files (e.g. .c and .h files) uploaded to the remote execution cache, should not be uploaded to the other central cache instance. The FindMissingBlobs requests from bazel client then results in huge amount of HEAD requests that would be unnecessary to forward via the proxy.
I'm not working on a pull request for this now, instead I'm focusing on https://github.com/buchgr/bazel-remote/pull/350
Allow configuring the constants in httpproxy.go, from configuration file:
And specifically allow numUploaders to be set to 0. That would mean that bazel-remote will try fetching from parent cache, but never uploading anything to parent cache.
Optionally also allow disabling forwarding of HEAD requests via proxy.
Use cases:
Set to zero if the local bazel-remote instance mostly contains artifacts irrelevant for the parent cache. But there is chance of cache hits in other direction.
Set to zero if the executor using the local bazel-remote instance is not trusted enough to populate a central shared cache.
Set to zero if the remote execution input files uploaded to a specific remote execution cache instance, should not be distributed futher to also central cache instance. But if the remote executor should still get build result cache hits from central cache. (For this use case it could also make sense to disable forwarding of HEAD requests, and only forward GET requests).
Reduce number of uploaders based on what a parent central cache could handle, to avoid overload conditions. (Not sure if it would work i practice or if a single uploader would still consume almost as much resources)