Version 2.5 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.

Glossary

Glossary

Components

  • Client: A machine that runs Bazel – typically your workstation. Connects to Schedulers, sends execution requests and downloads output files. Can be a virtual machine co-located with the Remote Execution cluster to have higher bandwidth to Schedulers and achieve better performance.

  • Scheduler: Containerized process. It accepts execution requests from the Client(s), and dispatches them to available Workers. A cluster requires at least one Scheduler, but typically there are more, and the Client(s) usually connect to them via a Load Balancer.

  • Worker: Containerized process. It runs build actions to serve the Client requests and participates in the CAS (see below). A cluster requires at least one Worker, but typically there are more. Workers can be configured to run one or more Execution services (see below), or not run any and operate in a CAS-only mode when it just replicates outputs but does not execute any actions (see --worker_config ).

Services

  • CAS (Content Addressable Storage): An internal storage service for build output files. Workers themselves act as the CAS nodes, there’s no separate CAS backend. This system stores, replicates, and serves build output files. The Client can download build outputs from the Remote Execution service; when it does, the files are served from the CAS. You can configure CAS behavior using CAS-related flags.

  • Replication: For sake of performance and reliability, CAS nodes replicate files. Replicated files have a minimum retention time, which should be long enough so files don’t get evicted while the build is running and subsequent actions may still need it, but short enough not to linger around too long and fill local CAS space.

  • Execution: The central service of Remote Execution, provided by Workers.

  • Action Cache: A service provided by Schedulers. The Action Cache stores metadata about recently executed build actions. When the Scheduler gets a request from the Client, the Scheduler checks if there’s an Action Cache entry for that request and whether all outputs are still available in the CAS. If so, the action is a cache hit and doesn’t need to be executed.

2022-04-28