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.
General terms¶
Cluster: A collection of virtual machines, networks, load balancers, and other cloud resources that run a set of services together. Typically, EngFlow deploys a remote execution cluster into a single dedicated AWS subaccount or GCP project.
Co-managed cluster: A cluster operated by EngFlow, deployed into an AWS subaccount or GCP project owned by a customer. The cloud provider bills the customer directly. This may be advantageous for customers with negotiated discounts with cloud providers and customers with special security or networking requirements.
Fully-managed cluster: A cluster operated entirely by EngFlow, deployed into an AWS subaccount or GCP project created by EngFlow. Compare with co-managed cluster and self-managed cluster.
Pool: A pool is a group of identically configured worker instances in a cluster that can be scaled up or down independently of other pools. Each cluster has a default pool and may have additional pools depending on the customer's use case.
Self-managed cluster: A cluster operated entirely by a customer. EngFlow provides binaries and other release artifacts but does not directly support the cluster.