search

bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
23.25k stars 4.08k forks source link

Bazel remote execution services capabilities #7476

Closed t-chaik closed 5 years ago

t-chaik commented 5 years ago

Description of the problem / feature request:

In remote execution mode, Bazel allow specifying two separate remote execution service end-points:

In order to determine client/server compatibility, Bazel's first gRPC call to the remote service is GetCapabilities() in order to retrieve ServerCapabilities. This message contains, among other informations, ExecutionCapabilities and CacheCapabilities.

Currently, if both --remote_executor and --remote_cache are set, it seems like Bazel is only querying ServerCapabilities at the --remote_executor end-point and determines compatibility using both ExecutionCapabilities and CacheCapabilities from that message.

This is a bit surprising, and, even if the REAPI specification does not mention anything regarding this, expected logic in that situation, I believe, would have been to query capabilities from the two end-point services and use ExecutionCapabilities from --remote_executor and CacheCapabilities from --remote_cache.

What operating system are you running Bazel on?

Debian Linux testing.

What's the output of bazel info release?

release 0.22.0- (@non-git)

Any other information, logs, or outputs that you want to share?

I'll fill a bug against the REAPI for better documentation about the expected behaviour once that behaviour is determined and agreed.

buchgr commented 5 years ago

Thanks for the report Martin. I believe at the time @ola-rozenfeld implemented the capabilities query we were aware of this, but then decided to only query one endpoint. Do you recall why @ola-rozenfeld?

ola-rozenfeld commented 5 years ago

Yes, let's continue this discussion in the remote-apis repository. We probably do need to clarify this. I remember the reasons we had for designing it this way -- the alternative ended up requiring a lot more complexity, because of the subtle bundling of execution and cache endpoints. We decided to require the execution endpoint to provide the full capabilities of the service as a whole.

t-chaik commented 5 years ago

Yes, let's continue this discussion in the remote-apis repository.

I've opened https://github.com/bazelbuild/remote-apis/issues/61 for this.