[nomad-prep] P2 — dispatcher refactor: pluggable launcher + DISPATCHER_BACKEND flag #802

New issue

Closed

opened 2026-04-15 18:12:13 +00:00 by dev-bot · 0 comments

dev-bot commented

2026-04-15 18:12:13 +00:00

Collaborator

Part of the Nomad+Vault migration prep backlog. Blocked by: #793 — P3 (load_secret() in lib/env.sh).

Goal

Refactor docker/edge/dispatcher.sh so the "launch a vault runner" code path is behind a single pluggable function, with DISPATCHER_BACKEND={docker,nomad} selecting the implementation. Only docker is implemented here; nomad lands as a pure addition during migration Step 5.

Scope

Current state: dispatcher.sh contains multiple inline docker run --rm ... command builds (action dispatch + alt-mode dispatches).

Refactor into:

launch_runner ACTION_ID SECRETS_CSV MOUNTS_CSV — the one function that actually starts a runner.
Backend selector: DISPATCHER_BACKEND env var (default docker). Dispatches to _launch_runner_docker or _launch_runner_nomad.
_launch_runner_nomad implemented as a stub that errors "not implemented" so tests catch accidental selection.
All PR-verification, TOML validation, result.json write logic stays backend-agnostic (they already are; just ensure they don't call docker run directly).

Consume $(load_secret NAME) from P3 for any secret read inside the dispatcher (remove inline sops decrypt if present; let load_secret handle it).

Acceptance criteria

DISPATCHER_BACKEND=docker (or unset) behaves identically to current on live stack — end-to-end vault action completes, result.json committed.
DISPATCHER_BACKEND=nomad exits 1 with "nomad backend not yet implemented" and does not touch state.
shellcheck docker/edge/dispatcher.sh clean.
No duplication of secret-access logic; all secret reads via load_secret.

Why

Step 5 of the migration adds the nomad branch (a ~30-line nomad job dispatch-based impl). Doing the refactor now — on the live docker stack where regressions are visible immediately — separates risk: refactor now, add-backend later.

Labels / meta

[nomad-prep] P2 — blocked by #793.

Part of the Nomad+Vault migration prep backlog. **Blocked by: #793 — P3 (`load_secret()` in `lib/env.sh`).** ## Goal Refactor `docker/edge/dispatcher.sh` so the "launch a vault runner" code path is behind a single pluggable function, with `DISPATCHER_BACKEND={docker,nomad}` selecting the implementation. Only `docker` is implemented here; nomad lands as a pure addition during migration Step 5. ## Scope Current state: `dispatcher.sh` contains multiple inline `docker run --rm ...` command builds (action dispatch + alt-mode dispatches). Refactor into: - `launch_runner ACTION_ID SECRETS_CSV MOUNTS_CSV` — the one function that actually starts a runner. - Backend selector: `DISPATCHER_BACKEND` env var (default `docker`). Dispatches to `_launch_runner_docker` or `_launch_runner_nomad`. - `_launch_runner_nomad` implemented as a stub that errors "not implemented" so tests catch accidental selection. - All PR-verification, TOML validation, result.json write logic stays backend-agnostic (they already are; just ensure they don't call `docker run` directly). Consume `$(load_secret NAME)` from P3 for any secret read inside the dispatcher (remove inline sops decrypt if present; let `load_secret` handle it). ## Acceptance criteria - `DISPATCHER_BACKEND=docker` (or unset) behaves identically to current on live stack — end-to-end vault action completes, `result.json` committed. - `DISPATCHER_BACKEND=nomad` exits 1 with "nomad backend not yet implemented" and does not touch state. - `shellcheck docker/edge/dispatcher.sh` clean. - No duplication of secret-access logic; all secret reads via `load_secret`. ## Why Step 5 of the migration adds the nomad branch (a ~30-line `nomad job dispatch`-based impl). Doing the refactor now — on the live docker stack where regressions are visible immediately — separates risk: refactor now, add-backend later. ## Labels / meta - `[nomad-prep] P2` — blocked by #793.