2023-11-08 08:11:00 +00:00
|
|
|
# Copyright © 2022, 2023 Vulcanize
|
|
|
|
|
|
|
|
|
|
# This program is free software: you can redistribute it and/or modify
|
|
|
|
|
# it under the terms of the GNU Affero General Public License as published by
|
|
|
|
|
# the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
# (at your option) any later version.
|
|
|
|
|
|
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
# GNU Affero General Public License for more details.
|
|
|
|
|
|
|
|
|
|
# You should have received a copy of the GNU Affero General Public License
|
|
|
|
|
# along with this program. If not, see <http:#www.gnu.org/licenses/>.
|
|
|
|
|
|
2023-12-06 05:56:58 +00:00
|
|
|
import hashlib
|
|
|
|
|
import os
|
2023-11-08 08:11:00 +00:00
|
|
|
from pathlib import Path
|
|
|
|
|
|
2023-11-30 03:50:53 +00:00
|
|
|
from stack_orchestrator import constants
|
2023-12-06 05:56:58 +00:00
|
|
|
from stack_orchestrator.util import get_yaml
|
2023-11-08 08:11:00 +00:00
|
|
|
from stack_orchestrator.deploy.stack import Stack
|
|
|
|
|
from stack_orchestrator.deploy.spec import Spec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class DeploymentContext:
|
|
|
|
|
deployment_dir: Path
|
2023-12-06 05:56:58 +00:00
|
|
|
id: str
|
feat(k8s): decouple deployment-id from cluster-id
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>
2026-04-21 05:27:11 +00:00
|
|
|
deployment_id: str
|
2023-11-08 08:11:00 +00:00
|
|
|
spec: Spec
|
|
|
|
|
stack: Stack
|
|
|
|
|
|
|
|
|
|
def get_stack_file(self):
|
2023-11-30 03:50:53 +00:00
|
|
|
return self.deployment_dir.joinpath(constants.stack_file_name)
|
2023-11-08 08:11:00 +00:00
|
|
|
|
|
|
|
|
def get_spec_file(self):
|
2023-11-30 03:50:53 +00:00
|
|
|
return self.deployment_dir.joinpath(constants.spec_file_name)
|
2023-11-08 08:11:00 +00:00
|
|
|
|
|
|
|
|
def get_env_file(self):
|
2023-11-30 03:50:53 +00:00
|
|
|
return self.deployment_dir.joinpath(constants.config_file_name)
|
2023-11-08 08:11:00 +00:00
|
|
|
|
2023-12-06 05:56:58 +00:00
|
|
|
def get_deployment_file(self):
|
|
|
|
|
return self.deployment_dir.joinpath(constants.deployment_file_name)
|
|
|
|
|
|
|
|
|
|
def get_compose_dir(self):
|
|
|
|
|
return self.deployment_dir.joinpath(constants.compose_dir_name)
|
|
|
|
|
|
2026-01-22 08:06:45 +00:00
|
|
|
def get_compose_file(self, name: str):
|
|
|
|
|
return self.get_compose_dir() / f"docker-compose-{name}.yml"
|
|
|
|
|
|
2023-12-06 05:56:58 +00:00
|
|
|
def get_cluster_id(self):
|
feat(k8s): decouple deployment-id from cluster-id
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>
2026-04-21 05:27:11 +00:00
|
|
|
"""Identifier of the kind cluster this deployment attaches to.
|
|
|
|
|
|
|
|
|
|
Shared across deployments that join the same kind cluster. Used
|
|
|
|
|
for the kube-config context name (`kind-{cluster-id}`) and for
|
|
|
|
|
kind cluster lifecycle ops.
|
|
|
|
|
"""
|
2023-12-06 05:56:58 +00:00
|
|
|
return self.id
|
2023-11-08 08:11:00 +00:00
|
|
|
|
feat(k8s): decouple deployment-id from cluster-id
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>
2026-04-21 05:27:11 +00:00
|
|
|
def get_deployment_id(self):
|
|
|
|
|
"""Identifier of this particular deployment's k8s resources.
|
|
|
|
|
|
|
|
|
|
Distinct per deployment even when multiple deployments share a
|
|
|
|
|
cluster. Used as compose_project_name → app_name → prefix for
|
|
|
|
|
all k8s resource names (PVs, ConfigMaps, Deployments, …).
|
|
|
|
|
|
|
|
|
|
Backward compat: for deployment.yml files written before this
|
|
|
|
|
field existed, falls back to cluster-id so existing on-disk
|
|
|
|
|
resource names remain stable (no PV renames, no re-bind).
|
|
|
|
|
"""
|
|
|
|
|
return self.deployment_id
|
|
|
|
|
|
2026-01-22 08:06:45 +00:00
|
|
|
def init(self, dir: Path):
|
|
|
|
|
self.deployment_dir = dir.absolute()
|
2023-11-08 08:11:00 +00:00
|
|
|
self.spec = Spec()
|
|
|
|
|
self.spec.init_from_file(self.get_spec_file())
|
|
|
|
|
self.stack = Stack(self.spec.obj["stack"])
|
|
|
|
|
self.stack.init_from_file(self.get_stack_file())
|
2023-12-06 05:56:58 +00:00
|
|
|
deployment_file_path = self.get_deployment_file()
|
|
|
|
|
if deployment_file_path.exists():
|
2025-10-16 17:55:44 +00:00
|
|
|
obj = get_yaml().load(open(deployment_file_path, "r"))
|
|
|
|
|
self.id = obj[constants.cluster_id_key]
|
feat(k8s): decouple deployment-id from cluster-id
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>
2026-04-21 05:27:11 +00:00
|
|
|
# Fallback to cluster-id for deployments created before the
|
|
|
|
|
# deployment-id field was introduced. Keeps existing resource
|
|
|
|
|
# names stable across this upgrade.
|
|
|
|
|
self.deployment_id = obj.get(
|
|
|
|
|
constants.deployment_id_key, self.id
|
|
|
|
|
)
|
2023-12-06 05:56:58 +00:00
|
|
|
# Handle the case of a legacy deployment with no file
|
|
|
|
|
# Code below is intended to match the output from _make_default_cluster_name()
|
|
|
|
|
# TODO: remove when we no longer need to support legacy deployments
|
|
|
|
|
else:
|
|
|
|
|
path = os.path.realpath(os.path.abspath(self.get_compose_dir()))
|
|
|
|
|
unique_cluster_descriptor = f"{path},{self.get_stack_file()},None,None"
|
|
|
|
|
hash = hashlib.md5(unique_cluster_descriptor.encode()).hexdigest()[:16]
|
|
|
|
|
self.id = f"{constants.cluster_name_prefix}{hash}"
|
feat(k8s): decouple deployment-id from cluster-id
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>
2026-04-21 05:27:11 +00:00
|
|
|
self.deployment_id = self.id
|
2025-11-25 03:05:35 +00:00
|
|
|
|
|
|
|
|
def modify_yaml(self, file_path: Path, modifier_func):
|
2026-01-24 21:48:11 +00:00
|
|
|
"""Load a YAML, apply a modification function, and write it back."""
|
2025-11-25 03:05:35 +00:00
|
|
|
if not file_path.absolute().is_relative_to(self.deployment_dir):
|
|
|
|
|
raise ValueError(f"File is not inside deployment directory: {file_path}")
|
|
|
|
|
|
|
|
|
|
yaml = get_yaml()
|
2026-01-24 21:48:11 +00:00
|
|
|
with open(file_path, "r") as f:
|
2025-11-25 03:05:35 +00:00
|
|
|
yaml_data = yaml.load(f)
|
|
|
|
|
|
|
|
|
|
modifier_func(yaml_data)
|
|
|
|
|
|
2026-01-24 21:48:11 +00:00
|
|
|
with open(file_path, "w") as f:
|
2025-11-25 03:05:35 +00:00
|
|
|
yaml.dump(yaml_data, f)
|