Volumes have no CLI, MCP, or console surface: v0.0.8 shipped an HTTP API and nothing else

open   by a73x

Volumes shipped in v0.0.8 with an HTTP API and nothing else. A tenant who wants durable storage has to hand-roll curl against the plane, which makes the feature effectively unavailable to anyone using eitri the way eitri asks to be used.

What exists today (internal/server/api/routes.go:269-293):

- POST   /api/v1/volume-claims        create a claim
- GET    /api/v1/volume-claims        list
- GET    /api/v1/volume-claims/{id}   read one
- DELETE /api/v1/volume-claims/{id}   delete

Attachment has no route at all. A claim is bound to a VM by passing `volume_claims` in the CreateVM body, inside the create transaction — so attach is create-only and there is no detach short of destroying the VM.

Missing surfaces:

- **CLI** — no `eitri volume` command of any kind. `cmd/eitri` does not mention volumes.
- **MCP** — no tool. An agent driving eitri over /mcp cannot create a claim, cannot list one, and cannot attach one when it creates a VM. This is the sharpest gap: MCP is how Claude drives the fleet, and volumes are invisible to it.
- **Console** — no page. `web/src` mentions volumes only in `lib/api-types.ts`, which is generated from the OpenAPI spec: the types are already there and nothing renders them.

Worth splitting from the surface question, because it is a design decision rather than plumbing: should attach/detach exist on a live VM, or does attachment stay a property of VM creation? The current model is deliberate — binding inside the create tx is what makes the claim/volume/attachment invariant simple — and exposing "attach" in a CLI or MCP tool will read as though a running VM can take a disk unless the verb is named for what it does. Decide that before designing the commands, or the surface will promise something the model does not do.

Related: the docs (docs/volumes.md) describe the API, so a user who reads them is told to use curl.