-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can not http proxy to another bazel-remote instance #524
Comments
Hi, this is a (hopefully temporary) limitation of the default compressed storage mode on the instance 2. If you add At some point I would like to make this work with compressed storage (and transfer compressed blobs between the two instances). |
Thanks for the quick reply @mostynb, that makes sense. This does lead to a few more questions on my part. The readme says:
But I noticed that Does that mean that the default |
Yes, that's right- but you can store more data in the cache, which might increase your cache hit rate. If the clients mostly download compressed data and bazel-remote is using compressed storage, it can just write those bytes directly. If clients upload compressed data bazel-remote still has to decompress it to verify the hash (and it then recompresses to allow downloads from non-zero offsets without decompressing the entire blob). BTW I don't recommend using bazel with |
Steps to reproduce
bazel-remote
instances, with one http proxying to the other:bazel remote 1:
bazel remote 2:
bazel-temote
:It seems like when attempting to perform HTTP proxying, bazel-remote tries to read and write to
/cas.v2/
, howeverbazel-remote
rejects these as bad requests. All these hashes do already exist on the filesystem, and if I manually do a curl for the same hash but at/cas/
, then things work as expected.Version
Latest release v2.3.3
Why am I trying this anyway
I'm somewhat interested in setting up a local caching layer for devs at my company, proxying to a shared cache for all developers. This is because a locally running bazel cache, once its cache is filled, is substantially faster.
The text was updated successfully, but these errors were encountered: