2026-11-04 — Docker runner warm-floor source

TL;DR

Issue #605 adds a default-off Docker warm-floor setting after the Reddit Explorer CI queue evidence in reddit_explorer#175 and PR #180. The source change preserves scale-to-zero at minimum_running_docker_vms: 0; it does not start VMs, install the scaler, change pool labels, or reserve capacity. A future nonzero setting requires explicit owner approval and an owner-operated scaler runtime refresh.

Phase status

Item	State
Default scale-to-zero	Preserved: Docker warm floor is 0
Warm-floor source support	Implemented for one or two distinct on-demand Docker guests
Live configuration	Not changed
Scaler runtime installation	Not performed
Per-repository Docker reservation	Not implemented

What shipped

infra/github-runners/hyperv-scaler/placements.yml now has minimum_running_docker_vms. The scaler validates the requested floor against the distinct eligible on-demand Docker guests and chooses them deterministically: gha-docker-a, then gha-docker-b. A floor guest is included in the scaler's keep set even without queued or busy work; non-floor idle guests keep the ordinary idle shutdown behavior.

The generated scaler map and tick result expose the configured floor and the selected warm guests. The Windows scaler writes warm_docker_floor into its heartbeat and logs warm-docker-floor when that policy starts a guest, separate from queued/in-progress and busy-runner reasons.

Known gaps

A warm floor keeps VM availability, not reserved capacity. The shared Docker pool can still be busy with work from another repository, so this source change does not guarantee a six-minute CI run. The selected guests also need to boot and register after an owner enables a nonzero floor; the first status check must confirm all intended Docker listeners are online before using it as an SLO control.

What remains

Owner

1. Before enabling a nonzero floor, approve the continuous Docker guest memory and power cost, and choose 1 or 2 based on the desired availability window.
2. After merge, refresh the pinned ProgramData scaler runtime through the existing elevated owner procedure; merging source does not alter that runtime.
3. Verify the heartbeat's warm_docker_floor, both guest states when using 2, and GitHub runner readiness before accepting a CI latency target.

Agent

1. Add a bounded warm-floor deployment/rollback procedure only after the owner approves a live policy value.
2. Investigate a reservation lane only if telemetry shows the warmed shared pool saturated by concurrent fleet work.

flowchart LR
  setting[minimum_running_docker_vms]
  setting --> zero[0: scale to zero]
  setting --> one[1: gha-docker-a]
  setting --> two[2: gha-docker-a and gha-docker-b]
  one --> heartbeat[warm_docker_floor status]
  two --> heartbeat
  heartbeat --> owner[Owner verifies listener readiness]