cluster-id plays two roles today: (a) which kind cluster this
deployment attaches to (used for the kube-config context name) and
(b) compose_project_name -> app_name, the prefix for every k8s
resource the deployment creates. _get_existing_kind_cluster() in
deploy create forces (a) to inherit the running cluster's name, and
because (a) and (b) are the same field, (b) inherits too — so two
deployments that share a cluster also share an app_name and collide
on every resource whose suffix isn't naturally distinct (PVs are
cluster-scoped; same-stack deployments collide there in particular).
Decouple: add a distinct `deployment-id` field. cluster-id keeps its
current behavior (inherit running cluster, else fresh). deployment-id
is always fresh per `deploy create`. K8sDeployer sources
kind_cluster_name from cluster-id and app_name from deployment-id.
Backward compatibility:
- Existing deployment.yml files have only cluster-id; no on-disk
change until the next `deploy create`.
- DeploymentContext.init() falls back: deployment-id = cluster-id
when the field is absent. Existing deployments keep their current
app_name and resource names on next start — no PV renames, no
re-binds, no data orphaning.
- `compose_project_name` parameter to K8sDeployer is retained (still
used by the compose deployer path); only the k8s-side internals
switch to deployment_context getters.
- The helm chart generator continues to derive chart names from
cluster-id; untouched here, worth a follow-up for consistency.
Effect on woodburn: dumpster/rpc/trashscan each already carry a
distinct cluster-id in their deployment.yml (pre-`_get_existing_kind_cluster`
era). Under the fallback, they all adopt their existing cluster-id
as deployment-id, so resource names are identical to today.
Effect on new deployments: even when they share a running cluster
(kind-cluster-name in kube-config matches cluster-id), they get
distinct deployment-ids at deploy create, and thus distinct resource
name prefixes. The same-stack PV collision the namespace ownership
check surfaces goes away by construction.
Test: run-deploy-test.sh now reads deployment-id from the new field,
falling back to cluster-id for pre-decouple fixtures.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ac4a509d6f