Define local PersistentVolume strategy for ComfyUI and game-server data #7

New issue

Closed

opened 2026-08-29 00:22:49 -05:00 by portegumi · 1 comment

portegumi commented

2026-08-29 00:22:49 -05:00

Collaborator

Description

Preserve large hardware-bound datasets in place while representing them safely in Kubernetes. Kubernetes local PersistentVolumes should be used instead of arbitrary hostPath mounts.

Scope

Document the existing ComfyUI asset location on the media server and game-server data location on the OptiPlex.
Define local PV naming, node affinity, permissions, capacity reporting, reclaim behavior, backup expectations, and failure recovery.
Define node labels, taints, tolerations, and workload affinity needed to keep these workloads on their data-owning nodes.
Avoid copying or restructuring existing data until an application-specific migration requires it.

Acceptance criteria

Local PV conventions for both nodes are documented.
Node-affinity and scheduling requirements prevent a volume-backed workload from moving to a node without its data.
Existing data remains in place and unchanged during strategy development.
Backup and node-failure limitations are explicitly documented.
No application is migrated as part of this issue.

Dependencies / blockers

Requires the OptiPlex and media server to be joined as workers. Application-specific cutovers remain separate work.

## Description Preserve large hardware-bound datasets in place while representing them safely in Kubernetes. Kubernetes `local` PersistentVolumes should be used instead of arbitrary `hostPath` mounts. ## Scope - Document the existing ComfyUI asset location on the media server and game-server data location on the OptiPlex. - Define local PV naming, node affinity, permissions, capacity reporting, reclaim behavior, backup expectations, and failure recovery. - Define node labels, taints, tolerations, and workload affinity needed to keep these workloads on their data-owning nodes. - Avoid copying or restructuring existing data until an application-specific migration requires it. ## Acceptance criteria - [ ] Local PV conventions for both nodes are documented. - [ ] Node-affinity and scheduling requirements prevent a volume-backed workload from moving to a node without its data. - [ ] Existing data remains in place and unchanged during strategy development. - [ ] Backup and node-failure limitations are explicitly documented. - [ ] No application is migrated as part of this issue. ## Dependencies / blockers Requires the OptiPlex and media server to be joined as workers. Application-specific cutovers remain separate work.

portegumi added the

storage

documentation

labels

2026-08-29 00:22:49 -05:00