-
Notifications
You must be signed in to change notification settings - Fork 119
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
Split the Capabilities by endpoints #76
Conversation
// GetCapabilities returns the server capabilities configuration of the | ||
// remote endpoint. | ||
// Only the capabilities of the services supported by the endpoint will | ||
// be returned. For example: |
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.
Is 'For example' necessary here? Couldn't we simply specify an exhaustive list?
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.
Hmm, I guess this is already an exhaustive list :-)
Maybe I missed this in a separate discussion but is it the case that we cannot host the ActionCache separately from the CAS? |
Correct, these two are linked.
…On Thu, May 9, 2019 at 4:04 PM Ed Baunton ***@***.***> wrote:
Maybe I missed this in a separate discussion but is it the case that we
cannot host the ActionCache separately from the CAS?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#76 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGFAVOGKO4A4DROZRSXNVUTPUR7UZANCNFSM4HL4PXIA>
.
|
According to changes in bazelbuild/remote-apis#76 (and discussion in bazelbuild/remote-apis#61): > Each endpoint should implement the Capabilities service, and populate the fields relevant to the services available at that endpoint. Clients may choose to ignore irrelevant capabilities if the client does not plan to use a given service on the specified endpoint. This PR: 1. Refactor `RemoteModule` to use a `ChannelFactory` when creating channels so that tests can mock into channels connected to a fake server. 2. Add tests for verifying server capabilities. 3. Only check required capabilities for a given endpoint. - If `--remote_executor` and `--remote_cache point` to the same endpoint, we require that endpoint has both execution and cache capabilities. - If they point to different endpoints, we check the endpoint with execution or cache capabilities respectively. Fixes #11901. Closes #12008. PiperOrigin-RevId: 329875749
Fixes #61.
Will need to fix Bazel to match!