[earakely-scale]

What this does

Part of FD-5321, related to FD-4538 (decision 14). Windows disks are now kept in the image store, as Linux disks are. Until now they stayed in the Docker of the machine that composed them.

• Composed disks are pushed and pinned. A Windows disk composed on a machine is pushed to the env's image store under its key and recorded by its pinned ref. A compose of the same inputs on any machine reuses it, and a deploy pulls it.
• The base is pushed too. The installed base goes to the store under a tag of its recipe (windows-base-<key>), with its evaluation's expiry and the ISO's sha256 as labels. A machine without the base pulls it rather than installing Windows (about 15 minutes) and fetching the ISO (about 6 GB).
• The base carries its admin key. Composing a layer reaches the guest over ssh as agentadmin, so the base image holds that key at /disk/admin.key. A machine that pulls the base takes the key out of it.
• The base key no longer includes the ISO's sha256. That would mean fetching the ISO only to find out a base is already stored. The ISO's sha256 is a label instead. As before, a base with fewer than 7 days of its evaluation left is installed afresh.
• The composed key follows the base's identity and expiry, not its local image id, so a machine that doesn't hold the base can still tell whether the store has the disk.

Removed: held, remove and image_id. A disk that fails its probe is no longer deleted from this machine, because the store keeps it. Its record says it failed, the same as for Linux disks.

Security note

The admin key lives in the base image, in the user's own image store. The guest's ssh is only ever reached on the composing machine's loopback while a layer is being composed. A deployed computer forwards only the driver's port, not ssh. Only the base, the layer's disk and the guest file go into a launcher image or a remote sandbox, never /disk/admin.key.

Tested

• Unit: tst/unit/env/envs/test_computer_windows.py (56 tests) with a fake registry. New cases cover:
  • reusing a disk the store holds;
  • a machine without the base takes the store's base unless its evaluation is near its end;
  • a renewed base is pushed.
• E2E on an EC2 c8i.4xlarge with nested KVM, against the local registry: see the comment below.

🤖 Generated with Claude Code

Confidence Score: 5/5

The reviewed changes appear safe to merge.

Summary

Windows bases and composed disks now live in the environment's image store.

• Windows composes can reuse a current base from the environment’s image store.
• Matching Windows composes reuse a pinned disk from the environment’s image store.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Choose Windows base] --> B{Valid local base?}
    B -->|Yes| C[Push if missing from store]
    B -->|No| D{Valid stored base?}
    D -->|Yes| E[Keep pinned base reference]
    D -->|No| F[Install and push base]
    C --> G{Composed disk stored?}
    E --> G
    F --> G
    G -->|Yes| H[Reuse pinned disk]
    G -->|No| I[Prepare base locally and compose]
    I --> J[Push and pin disk]
    H --> K[Probe and record result]
    J --> K

Loading

_{Reviews (3) · Last reviewed commit: "refactor(computer): one store lookup for..." · Reviewed by Greptile}

[earakely-scale]

E2E

Set-up: an EC2 c8i.4xlarge with nested KVM, running agent-env run tst/integration/computer/windows, with the local registry as the image store.

Run	What happened	Result
First compose	This PR changes the base's key, so Windows installed afresh. Then: push the base, compose the cua-driver layer, push the disk, gate 3.	probe passed, 1928 s in all. reset passed in 115 s.
A new env (another checkout's bundle path)	"reusing the disk of the same key, composed earlier", then gate 3.	passed (and on modal_vm, #534)
Fresh machine: empty XDG_STATE_HOME and XDG_CACHE_HOME, every Windows image removed from Docker	The compose reused the stored disk. No ISO fetch, no install, no base pull.	probe passed, 252 s
Fresh machine, new compose key (a file added to the driver's context)	Pulled the base from the store, took its admin key, installed the layer over ssh as agentadmin, pushed the new disk.	composed and pushed (see below)

About the new-key run. Its first gate-3 probe failed one check, "a recording's segments match their files" (4 frames over 0.59 s of a 2 s recording). At that moment the box was also exporting and compressing the 11.6 GB base for the Modal chaos test, on every core. The rerun on a quiet box treated the failed build as pending, reused the disk the store holds (a failed disk is no longer deleted), and passed gate 3 in 55 s and the probe in 112 s. The recording check under host load goes to W9 (FD-5330).

At the end, the registry held windows-base-cb035f605fa7bc2a and the two composed disks, each under its key.