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

a73x commented

2026-09-05 19:33:03 +00:00

(Migrated from git.a73x.sh)

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.

Migrated from git-collab issue 8b89d1971c786dd33212ec80c30a0c1b27eaee90.

Original author: a73x dev@a73x.sh.

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. --- Migrated from git-collab issue `8b89d1971c786dd33212ec80c30a0c1b27eaee90`. Original author: a73x <dev@a73x.sh>.