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 |
|
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-addressis still used.Currently, both the
CASservice (ByteStreamServer,ContentAddressableStorageServer) and theActionCacheservice (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 theExecutionservice on the same host as the remote store/cache, we have a separate--remote-execution-addressflag to allow for different deployment models.