Kind applies extraMounts only at cluster creation. When a deployment joins an existing shared cluster, any extraMount its kind-config declares that isn't already active on the running control-plane is silently ignored — PVs backed by those mounts fall through to the node's overlay filesystem and lose data on cluster destroy. Validate this up front in create_cluster(): - On cluster reuse, compare the new deployment's extraMounts against the live bind mounts on the control-plane container (via docker inspect). Fail with a DeployerException listing every mismatched mount and pointing at docs/deployment_patterns.md. - On first-time cluster creation without a /mnt umbrella mount (kind-mount-root unset), print a warning that future stacks may require a full recreate to add new host-path mounts. Document the umbrella-mount convention (kind-mount-root) and the migration path for existing clusters in docs/deployment_patterns.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| images | ||
| CONTRIBUTING.md | ||
| README.md | ||
| adding-a-new-stack.md | ||
| cli.md | ||
| deployment_patterns.md | ||
| docker-compose-deployment.md | ||
| fetching-containers.md | ||
| gitea-with-laconicd-fixturenet.md | ||
| helm-chart-generation.md | ||
| k8s-deployment-enhancements.md | ||
| laconicd-with-console.md | ||
| release-process.md | ||
| spec.md | ||
| webapp.md | ||
README.md
Stack Orchestrator
Here you will find information about the design of stack orchestrator, contributing to it, and deploying services/applications that combine two or more "stacks".
Most "stacks" contain their own README which has plenty of information on deploying, but stacks can be combined in a variety of ways which are document here, for example: