-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Support read-only access to remote cache #1188
Comments
Don’t you mean —remote-only? |
Currently, Treating the remote (or any) cache as readonly seems like a pretty reasonable feature request to me though. Our cache flags right now could use some cleanup, this might be a good opportunity to do so. |
Thats good to hear, appreciate the consideration. BTW turbo is amazing! The integration into our monorepo was drop dead simple, and we are reaping the benefits already! Thank you for all your hard work. |
@gsoltis Do you know where it stores information about giving up? And how to recover from it? I can't find any info about that. |
Stumbled over this problem rn. Any news? |
This was done in #6624 |
Describe the feature you'd like to request
I think there is a valid use case to allow read only access to a remote cache. For example your CI could be configured for read/write but devs on local machines should ONLY be able to READ if security is a concern (as is in our organization).
Describe the solution you'd like
Distinugish between TURBO_TOKEN and TURBO_READ_ONLY_TOKEN. If a read only token is configured then PUTs to the cache are not attempted.
Describe alternatives you've considered
We are using one of the open source implementations of the turbo cache. We deploy 2 instances of them and each are backed by the underlying same store (s3 via Min.io) such that they share the same artifacts. The first instance is configured with a read/write token to the store and intended to be used by CI, then second instance is configured with a read only token via a policy on the store to prevent writes (intended for local devs).
The issue is that when using the first instance (w/ read & write) I get 100% cache hits for a given operation. The second instance however returns a high number of intermittent cache misses (when there in fact should be hits) with dozens of the following error when running in verbose mode.
The remote cache logs as expected return 403s whenever a PUT is attempted (as expected). I don't quite understand what is happening underneath the hood, but it appears that there is a correlation when configuring the store to reject writes for a given token and that turbo is backing off GET requests and falling over to a cache miss. (At least that is my theory).
The alternative we're going to try is to have an nginx rule on the read only instance to intercept PUTs and simply return a 200 to see if turbo handles this better and enables a full read-only mode.
All this is a bit hand wavey so it would be awesome if there could be a supported path for this such that turbo itself doesn't assume READ and WRITE but can be configured as a READ only.
The text was updated successfully, but these errors were encountered: