-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Allow for configuring a separate remote cache address #15856
Conversation
[ci skip-build-wheels]
[ci skip-build-wheels]
[ci skip-build-wheels]
… and write)`. # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
…-headers` options. [ci skip-build-wheels]
Only the top commit is relevant: the rest is #15854. See discussion of whether the extra flag is necessary over here: #15854 (comment) As mentioned over there, the most pressing motivation is to allow the integration test of #15850 to use separate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe edit the help of --remote-store
to clarify how this is different? I don't really understand the difference.
Also bump that this requires changing our in-repo docs for remote caching. |
I was holding off on that until I saw a signal that people were in favor of landing the PR at all... if consensus is against adding the flag, then I'd need to take a different approach to testing for #15850. |
I'm generally skeptical of this PR, but not a hard no. I don't have enough realworld REAPI experience to know if we can expect users using a different server for CAS vs store |
Consensus was that there wasn't production justification for this. Will merge the |
Adds a separate
--remote-cache-address
. When not set, the--remote-store-address
is still used.Currently, both the
CAS
service (ByteStreamServer
,ContentAddressableStorageServer
) and theActionCache
service (ActionCacheServer
) are assumed to be hosted at a single--remote-store-address
. This is somewhat arbitrary: while it is common to host those service together, it is not required. And while it is also common to host theExecution
service on the same host as the remote store/cache, we have a separate--remote-execution-address
flag to allow for different deployment models.