Design cross-host volume migration and replication #131

New issue

Open

opened 2026-09-15 06:55:35 +00:00 by a73x · 0 comments

a73x commented

2026-09-15 06:55:35 +00:00

Owner

Design deliverables

Separate planned migration from replication/failover and choose an initial delivery scope.
Specify how sparse data transfers are authenticated, authorized, integrity-checked and resumed.
Define source quiescence and an atomic ownership/placement handover that prevents simultaneous writers.
Account for destination capacity and explain rollback and cleanup if transfer or cutover fails.
For replication, state consistency guarantees, acceptable data loss/downtime and how an unreachable former writer is fenced before failover.
Address backend/image architecture compatibility and operator-visible progress/failures.
Produce phased implementation issues and failure scenarios for verification.

References: docs/volumes.md; internal/server/store/volumes.go; internal/agent/reconcile/volumes.go. Migration and replication need explicit semantics before changing the current host-pinning invariant.

The first attachment permanently binds a claim to a host. Later attachments on another host are refused, and the local disk remains the only copy. This prevents moving a volume-backed workload between hosts and provides no recovery from loss of that disk. ## Design deliverables - Separate planned migration from replication/failover and choose an initial delivery scope. - Specify how sparse data transfers are authenticated, authorized, integrity-checked and resumed. - Define source quiescence and an atomic ownership/placement handover that prevents simultaneous writers. - Account for destination capacity and explain rollback and cleanup if transfer or cutover fails. - For replication, state consistency guarantees, acceptable data loss/downtime and how an unreachable former writer is fenced before failover. - Address backend/image architecture compatibility and operator-visible progress/failures. - Produce phased implementation issues and failure scenarios for verification. References: docs/volumes.md; internal/server/store/volumes.go; internal/agent/reconcile/volumes.go. Migration and replication need explicit semantics before changing the current host-pinning invariant.