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

Abierto
  • ¿Algo no está bien?
#553 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@yifanxuaaa ya está trabajando en esto.

Desde el 9/11/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
2.1k
Forks
110
Merge medio
23 h 52 min
PR fusionados (30 d)
138

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Ephemeral-AI-Lab/layerfs

Todos los issues de Ephemeral-AI-Lab/layerfs

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.