Roadmap relationship
Outcome
Model persistent storage independently from releases and workloads so operators can create, attach, inspect, resize where supported, back up, restore, detach, and delete volumes without accidental data loss.
Current gap
ts-cloud supports EFS and shared release paths and will need named volumes for multi-service/container workloads, but there is no unified inventory, mount editor, ownership model, dependency graph, backup policy link, or safe delete/detach workflow.
User experience
- List volumes with project/environment/service ownership, provider/type, capacity/usage, mount targets, backup/RPO status, encryption, age, and orphan state.
- Mount editor validates target path, mode, ownership, sharing, driver options, and restart/redeploy impact before applying.
- Deletion and detach flows enumerate affected workloads, recent backup, snapshots, and data-loss consequences.
- Service pages link mounted volumes; volume pages link all consumers and recovery points.
- Orphan detection offers adopt, attach, snapshot, or delete after a safe age rather than automatic removal.
Scope
- Define volume, mount, attachment, snapshot/recovery point, usage, and capability models.
- Support server directories/shared paths, Docker/named volumes, EBS/EFS, and provider equivalents where current drivers can operate them.
- Implement create/list/inspect/attach/detach/resize/snapshot/delete/adopt and filesystem usage discovery as capabilities allow.
- Integrate Compose/service manifests, runtime inventory, release deployment, backup policies, and disaster recovery.
- Add ownership/UID/GID/mode and mount propagation semantics only where safely supported.
Technical direction
- Use stable volume identity independent of release names and make attachment changes durable operations with workload locks.
- Discover observed attachments/provider resources and reconcile with desired mounts.
- Require health/drain/unmount checkpoints before detach/resize and report partial state precisely.
- Keep filesystem-specific commands in driver adapters with preflight checks.
Safety and operability
- Never delete a volume as an implicit consequence of deleting a service unless policy and confirmation explicitly select data deletion.
- Require recent verified backup or explicit override for destructive delete/format operations.
- Block dangerous host paths, traversal, device mounts, and cross-tenant attachments by default.
- Encrypt where supported and restrict snapshot/backup access to the same or narrower scope.
Acceptance criteria
- A persistent volume survives redeploy/release changes and remains linked to its service.
- Detach/delete cannot proceed while active consumers remain unless a documented force workflow is explicitly approved.
- Backup/restore state is visible and a restored volume can attach to a replacement workload.
- Unsupported resize/snapshot/mount semantics are explained before submission.
Verification
- Identity, attachment graph, orphan adoption, lock, drain/unmount, resize, delete, and path-policy tests.
- Driver fixtures for named volumes, server paths, and at least one cloud volume type.
- End-to-end create → attach → write → redeploy → backup → restore → detach flow.
Non-goals
- Building a distributed filesystem.
- Automatically moving live databases between arbitrary storage drivers.
- Treating ephemeral container layers as persistent volumes.