alkdev/alknet

0 Fork 0

Files

T

glm-5.2 1ce11717d8 docs(arch): draft alknet-docker architecture specs (ADRs 058-063, OQs 048-051)

Greenfield architecture spec set for the alknet-docker crate — a thin,
single-host bollard wrapper exposing docker container/image operations
as call-protocol ops on the shared alknet/call ALPN, plus a
DockerTtyBackend (impl TtyBackend) behind a tty feature for interactive
terminal sessions into containers over alknet/tty.

Six ADRs:
- 058: docker ops on alknet/call (no separate ALPN; raw-carriage handoff
  dissolved by alknet-tty extraction — interactive attach moved to
  alknet/tty via DockerTtyBackend, no carriage field on call.requested)
- 059: bollard 0.21 (verified current on crates.io) + feature selection
  (http+pipe+time; no ssl/ssh/websocket/buildkit)
- 060: container resource model (ADR-050 application) — alknet.managed/
  alknet.owner labels, list owned_only flag, hosted-services operator
  role via static-resource fallback, handler-driven revoke with
  autonomous-death tolerance, resource-action vocabulary
- 061: DockerTtyBackend in alknet-docker behind tty feature (attach vs
  exec mode; POC drive_attach_raw as reference)
- 062: Docker client + OwnershipStore injection via closure capture
  (not Capabilities, not OperationContext — matches from_openapi pattern)
- 063: exit code on terminal call.responded for non-interactive exec
  (call.completed stays empty, ADR-012 unchanged)

Four spec docs (crates/docker/): README, overview, docker-operations,
docker-tty-backend. Four deferred-scope OQs (048-051): network/volume
ops, buildkit, system events subscription, create options surface.

Updates the tty-backend.md Backend implementations table (DockerTtyBackend
row now specced) and the architecture README (doc table, ADR table,
current-state paragraph, OQ count).

Grounded in the alknet-docker POC (docs/research/alknet-docker/poc-summary.md)
which validated the hard parts; the remaining lifecycle ops are mechanical
bollard wrapping. Reviewed by architecture-reviewer subagent; criticals
(the docker_client injection model conflicting with the Capabilities
contract) resolved via ADR-062/063 before commit.

2026-07-08 09:29:22 +00:00

1.9 KiB

Raw Blame History

OQ-51: Container Create Options Surface

Origin: crates/docker/docker-operations.md §"Out of scope for v1"; crates/docker/docker-operations.md §"docker/container/create".
Status: deferred(scope)
Door type: Two-way
Priority: medium
Blocked on: v1 implementation. The v1 create input schema accepts the common fields (image, command, env, labels, name) and the full CreateContainerOptions surface (mounts, port bindings, networks, volumes, capabilities, etc.) is deferred to the implementation pass, where the input JSON Schema can be designed against bollard's Config struct and tested against real create calls. This is not an architectural decision (the create operation is already decided — ADR-060 §5); it's a schema-detail decision best made with the bollard types in hand.
Resolution: Not yet decidable. bollard's create_container takes a Config struct (container.rs:296) with ~40 fields (Image, Cmd, Env, Labels, HostConfig with mounts/ports/ networks/etc.). The v1 input schema accepts the high-frequency fields and omits the long tail; the full surface is a JSON Schema design task (which fields are required, which are optional, how HostConfig is nested, how the alknet.* labels merge with caller labels). The deferral is to the implementation pass, not past it — the schema is finalized when register_docker_ops is written and tested. The OperationSpec.input_schema is the one-way surface; its exact field set is a two-way-door refinement within it.
Cross-references: ADR-060 §5 (create records ownership — the architectural decision this OQ defers the schema details of), crates/docker/docker-operations.md §"docker/container/create"

1.9 KiB Raw Blame History

OQ-51: Container Create Options Surface

1.9 KiB

Raw Blame History