tree: 39ba453f8a8f2b972a52d6d487834df7532c2163 [path history] [tgz]
  1. api/
  2. app/
  3. cmd/
  4. devcfg/
  5. docker/
  6. index.yaml
  7. Makefile


QScheduler-Swarming is an implementation of the ExternalScheduler API for swarming, using the quotascheduler algorithm.

This server runs on Kubernetes.

Code layout:

  • api/ Definitions for the Admin API to QScheduler-Swarming.
  • app/config Definitions for QScheduler-Swarming configuration.
  • app/eventlog BigQuery logging helper.
  • app/frontend Request handlers.
  • app/state Common code for mutating scheduler state, and request-batcher implementation.
  • app/state/metrics Time-series and analytics emission.
  • app/state/nodestore Datastore-backed store of scheduler state with in-memory cache, distributed over many write-only datastore entities.
  • app/state/operations State mutators for scheduling requests.
  • cmd/qscheduler-swarming Entry point for server.
  • docker Context directory for Docker (including Dockerfile)

Making changes

Submitted changes are automatically deployed to the staging instance by Chrome Ops Kubernetes automation. It usually takes 5-10 min. To quickly check what version is currently running, visit /healthz endpoint and look at the image tag. It looks like ci-2020.04.10-30467-b307348. The last part is a git revision of infra.git repository used to build the image from.

Once a change is verified on the staging, land a channels.json CL that makes stable version equal to the current staging version there. It will result in the production cluster update.

If you want to deploy an uncommitted change to the staging cluster, follow instructions in dev/ Note that there‘s only one staging instance and you’ll be fighting with the automation to deploy changes to it (unless the automation is disabled).

To make changes to Kubernetes configuration, modify files in projects/qscheduler in k8s.git repo. Changes are applied on commit. See Chrome Ops Kubernetes for all details.