kaykayyali/damascus-orchestrator
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

orchestrator bind-mount per project is a config liability — make /opt/damascus/bmad/* auto-pickup #29

New Issue
Open
opened 2026-06-26 22:56:48 +00:00 by kaykayyali · 0 comments
kaykayyali commented 2026-06-26 22:56:48 +00:00
Owner
Copy Link

Problem

Every new BMAD project requires:

  1. Adding a bind-mount line to damascus-orchestrator/docker-compose.yml
  2. docker compose up -d --force-recreate --no-deps orchestrator to pick it up

This is a per-project friction point that scales linearly. After ~5 projects the volumes: block is unmaintainable, and the orchestrator container becomes a chicken-and-egg dependency for any new project.

Repro

docker compose up -d --build orchestrator — new projects under /opt/damascus/bmad/<new-project>/_bmad-output are invisible inside the container until a --force-recreate happens. Even docker compose restart orchestrator does NOT pick up the new mount (verified 2026-06-26).

The pre-flight validator test-ingest.sh already catches this case and prints the canonical fix recipe; we just need the orchestrator to not need the fix.

Proposed solutions (descending preference)

A. Auto-mount via a sidecar discoverer

Replace the explicit per-project bind-mount list with a sidecar container (or entrypoint script) that watches /root/*-prds/_bmad-output/ (or a configured glob) and bind-mounts each into /opt/damascus/bmad/<project-name>/_bmad-output:ro at orchestrator startup. New projects auto-show up; no compose edits.

B. NFS/shared-volume mount

Replace the per-project bind-mount list with a single shared volume mount like ./bmad:/opt/damascus/bmad populated by the host via a sync script (or systemd path unit that watches a known directory tree). Compose stays stable; new projects just need their _bmad-output/ dropped into ./bmad/<project>/.

C. Discovery at ingest time

damascus ingest --project X --path /root/X/_bmad-output reads from the host path directly via docker exec -e BMAD_DIR=... — no bind-mount needed at all. The orchestrator mount_source for BMAD resolution becomes the env var instead of the filesystem.

D. Single mega-mount

/root:/root:ro — mount the entire /root tree. New projects auto-pickup. Downside: orchestrator can now see everything under /root (security/leakage surface), and host-specific tooling assumptions leak in.

Recommendation

Option C (discovery at ingest time) is the cleanest — it removes the bind-mount from the data path entirely, making the orchestrator stateless w.r.t. project location. The ingest command becomes the contract; the orchestrator only needs read access during ingest, not permanent mount.

Workaround (until fixed)

For now, add to damascus-orchestrator/docker-compose.yml volumes::

- /root/<project>-prds/_bmad-output:/opt/damascus/bmad/<project>/_bmad-output:ro

Then docker compose up -d --force-recreate --no-deps orchestrator.

Filed

2026-06-26, while onboarding kaykayyali/lore-engine-merge (7-phase epic, see lore.wiki → [[2026-06-26 Lore Engine GraphMCP Merge]]). The first 4 BMAD projects (restitution, mindmaps, damascus-roadmap, hello-bmad) follow this pattern; the 5th (lore-engine-merge) is what made the friction visible enough to file.

## Problem Every new BMAD project requires: 1. Adding a bind-mount line to `damascus-orchestrator/docker-compose.yml` 2. `docker compose up -d --force-recreate --no-deps orchestrator` to pick it up This is a per-project friction point that scales linearly. After ~5 projects the `volumes:` block is unmaintainable, and the `orchestrator` container becomes a chicken-and-egg dependency for any new project. ## Repro `docker compose up -d --build orchestrator` — new projects under `/opt/damascus/bmad/<new-project>/_bmad-output` are invisible inside the container until a `--force-recreate` happens. Even `docker compose restart orchestrator` does NOT pick up the new mount (verified 2026-06-26). The pre-flight validator `test-ingest.sh` already catches this case and prints the canonical fix recipe; we just need the orchestrator to not need the fix. ## Proposed solutions (descending preference) ### A. Auto-mount via a sidecar discoverer Replace the explicit per-project bind-mount list with a sidecar container (or entrypoint script) that watches `/root/*-prds/_bmad-output/` (or a configured glob) and bind-mounts each into `/opt/damascus/bmad/<project-name>/_bmad-output:ro` at orchestrator startup. New projects auto-show up; no compose edits. ### B. NFS/shared-volume mount Replace the per-project bind-mount list with a single shared volume mount like `./bmad:/opt/damascus/bmad` populated by the host via a sync script (or systemd path unit that watches a known directory tree). Compose stays stable; new projects just need their `_bmad-output/` dropped into `./bmad/<project>/`. ### C. Discovery at ingest time `damascus ingest --project X --path /root/X/_bmad-output` reads from the host path directly via `docker exec -e BMAD_DIR=...` — no bind-mount needed at all. The orchestrator `mount_source` for BMAD resolution becomes the env var instead of the filesystem. ### D. Single mega-mount `/root:/root:ro` — mount the entire `/root` tree. New projects auto-pickup. Downside: orchestrator can now see everything under `/root` (security/leakage surface), and host-specific tooling assumptions leak in. ## Recommendation **Option C** (discovery at ingest time) is the cleanest — it removes the bind-mount from the data path entirely, making the orchestrator stateless w.r.t. project location. The `ingest` command becomes the contract; the orchestrator only needs read access during ingest, not permanent mount. ## Workaround (until fixed) For now, add to `damascus-orchestrator/docker-compose.yml` `volumes:`: ```yaml - /root/<project>-prds/_bmad-output:/opt/damascus/bmad/<project>/_bmad-output:ro ``` Then `docker compose up -d --force-recreate --no-deps orchestrator`. ## Filed 2026-06-26, while onboarding `kaykayyali/lore-engine-merge` (7-phase epic, see `lore.wiki` → `[[2026-06-26 Lore Engine GraphMCP Merge]]`). The first 4 BMAD projects (restitution, mindmaps, damascus-roadmap, hello-bmad) follow this pattern; the 5th (lore-engine-merge) is what made the friction visible enough to file.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
kaykayyali
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kaykayyali/damascus-orchestrator#29
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?