B4: Windows via a WSL2 worker and Docker backend (blocked on D2/O5)

Aperta
  • Qualcosa non va?
#553 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@yifanxuaaa ci sta già lavorando.

Dal 9/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

new feature

Parent: #545 (index). This issue owns the B4 Windows / WSL2 slice and is blocked on D2 (Windows/WSL2, #527) and #533 O5.

Summary

#545 B4 is 0/4 done, 1/4 partial and 2/4 N/A. The contract is clear — a WSL2 worker plus a Docker backend, no new daemon protocol, the machine record decides subsequent calls, and WSL2 is a machine + backend rather than a new isolation class — but the implementation must not start before D2 fixes the Windows route and #533 O5.

This issue records the contract and the acceptance so the slice can start the day D2 closes; it does not implement anything before then.

Scope (from #545 B4)

  • start with a WSL2 worker + Docker backend. (B4-214)
  • add no new daemon protocol. (B4-215; N/A until implementation)
  • the machine record decides subsequent calls. (B4-216; the principle already holds in #529/#536, the WSL2 proof does not)
  • WSL2 is a machine + backend (native / namespaces or docker), not a new isolation class. (B4-217; N/A until implementation)

Contract

  • A WSL2 worker is a normal machine worker; the control plane reaches it the same way it reaches an ssh host.
  • The backend inside WSL2 is docker (or native / namespaces); Windows is not an isolation class and never becomes a Machine.kind vendor enum.
  • The machine record carries the WSL2 route; every subsequent call is decided by the record, not by a platform branch.
  • No new daemon protocol and no per-platform forked protocol.
  • The same workspace.exec semantics hold on WSL2 as on native Linux / Docker.

Blocked on

  • D2 / #527: the Windows decision.
  • #533 O5: the isolation model that says WSL2 is a machine + backend.
  • Until then: do not write the adapter; keep the contract and the tests as a design record.

Acceptance (after D2)

  • machine.create / machine.start starts a WSL2 worker and a Docker backend.
  • The machine record decides every subsequent call; no new daemon protocol is introduced.
  • The same workspace.exec call matrix passes on WSL2, native Linux and Docker.
  • doctor reports WSL2 availability through the declared backend capability, not a Windows-specific branch.
  • WSL2 appears as isolation_class: container (or process for native), never as a new kind.

Non-goals

  • The Windows-native transparent Workspace proposal (#454) is a different layer.
  • Provider adapters are the B7 issue.

Related

  • Parent index: #545
  • B0 contract: #551
  • B5 lifecycle: #548
  • B6 scratch: #549
  • B9 worker health: #550
  • StoragePlacement guard: #552
  • B4 WSL2: #553
  • B7 cloud/provider: #554
  • Step runtime: #555
  • #547 is the daemon-admission follow-up: a different custody layer, not this sub-issue.
Lingua principale
Rust
Stelle
2.1k
Fork
110
Merge medio
23h 52m
PR unite (30g)
138

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ephemeral-AI-Lab/layerfs

Tutte le issue di Ephemeral-AI-Lab/layerfs

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.