feat(creator): OmniVoice deploy unit for SPARK (Dockerfile + compose + make + acceptance) [validate-on-node] - #1845
Conversation
…cceptance) [validate-on-node] Turn the OmniVoice voice server (omnivoice_server.py) from a manual `python omnivoice_server.py` into a managed fleet service for the SPARK node (NVIDIA DGX Spark, GB10 Grace-Blackwell, arm64 + CUDA, 128GB unified). - Dockerfile.omnivoice: multiarch (amd64+arm64) on nvidia/cuda runtime base (CUDA_BASE_TAG ARG). torch/torchaudio installed via ARG-driven index URL (TORCH_INDEX_URL, default cu128); SPARK arm64 needs the arm64/sbsa CUDA wheel (TODO-confirm-on-node). GPU via the NVIDIA container runtime, not baked in. Binds 0.0.0.0:8002, /healthz HEALTHCHECK, no secrets baked. - Makefile: omnivoice-build / omnivoice-up / omnivoice-down targets driving the service-local compose under the `voice` profile. - SPARK_DEPLOY.md: acceptance/validation doc mirroring ROCM_VALIDATION.md — arm64/sbsa torch wheel swap (TODO-confirm-on-node), /healthz + token-gated /synthesize + 24kHz WAV smoke via scripts/rocm_smoke.sh pointed at :8002, a "do not route live voice to SPARK until these pass" gate, and a P7/PBnJ launch section (pbnj/ tree is Pinokio-side, not in repo). The compose service (docker-compose.omnivoice.yml) is a damage-control-protected `docker-compose*.yml` path (compose Known Road, matched by basename even when service-local). It could not be written in-session without the KNOWN_ROAD env, so the full paste-ready YAML + the operator Known-Road steps live in SPARK_DEPLOY.md § 3a (plus an optional root-level fleet-compose integration in § 3c). Scaffold only: no SPARK/arm64/GPU in the authoring environment. Image NOT built, server NOT run or GPU-tested here. All node-specific steps are TODO-confirm-on-node. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 36 minutes and 39 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Docker Hardening ValidationHardening Validation ReportValidated: Sat Jun 20 04:15:49 UTC 2026Services CheckedPMOVES.AI Docker Hardening Validation[INFO] Checking: pmoves/docker-compose.hardened.yml [INFO] Validating: hi-rag-gateway-v2 [INFO] Validating: extract-worker [INFO] Validating: langextract [INFO] Validating: presign [INFO] Validating: render-webhook [INFO] Validating: retrieval-eval [INFO] Validating: pdf-ingest [INFO] Validating: jellyfin-bridge [INFO] Validating: invidious-companion-proxy [INFO] Validating: ffmpeg-whisper [INFO] Validating: media-video [INFO] Validating: media-audio [INFO] Validating: hi-rag-gateway-v2-gpu [INFO] Validating: hi-rag-gateway-gpu [INFO] Validating: deepresearch [INFO] Validating: supaserch [INFO] Validating: publisher-discord [INFO] Validating: mesh-agent [INFO] Validating: nats-echo-req [INFO] Validating: nats-echo-res [INFO] Validating: comfy-watcher [INFO] Validating: grayjay-plugin-host [INFO] Validating: agent-zero [INFO] Validating: archon [INFO] Validating: channel-monitor [INFO] Validating: pmoves-yt [INFO] Validating: notebook-sync [INFO] Validating: supabase_service_role_key [INFO] Validating: supabase_jwt_secret ====================================== |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5774941f7e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| .PHONY: omnivoice-build omnivoice-up omnivoice-down | ||
| omnivoice-build: ## Build the OmniVoice voice-server image (amd64 default; pass OMNIVOICE_PLATFORM=linux/arm64 for SPARK) | ||
| @test -f "$(OMNIVOICE_COMPOSE)" || (echo "✖ $(OMNIVOICE_COMPOSE) missing — operator must install it from SPARK_DEPLOY.md (compose Known Road)" && exit 1) |
There was a problem hiding this comment.
In a clean checkout these new omnivoice-build/omnivoice-up targets fail before doing any work because $(OMNIVOICE_COMPOSE) points at services/creator-operator/docker-compose.omnivoice.yml, but that file is not tracked or generated here (I checked git ls-files '*docker-compose.omnivoice.yml'/fd; only references are in this Makefile and the deploy doc). That makes the advertised Make entry points unusable unless every operator manually creates an untracked file first, so the deploy unit is incomplete in the repo.
Useful? React with 👍 / 👎.
| docker compose -f services/creator-operator/docker-compose.omnivoice.yml --profile voice build \ | ||
| --build-arg OMNIVOICE_TORCH_INDEX_URL=<arm64-sbsa-cu12x-index> # TODO-confirm-on-node |
There was a problem hiding this comment.
When an operator follows this command to select the arm64/sbsa wheel, the override is a no-op: Docker/Compose --build-arg sets Dockerfile build-time variables by name, but Dockerfile.omnivoice declares ARG TORCH_INDEX_URL, not OMNIVOICE_TORCH_INDEX_URL (the compose snippet only maps that env var during interpolation). On SPARK this leaves the default x86 cu128 index in place and the build still tries the incompatible wheel; use --build-arg TORCH_INDEX_URL=... or set OMNIVOICE_TORCH_INDEX_URL=... in the shell before invoking Compose.
Useful? React with 👍 / 👎.
…#1846) * feat(creator): commit real OmniVoice compose file (omnivoice.compose.yml) #1845 left the compose as a doc snippet because docker-compose*.yml is guard- protected by basename. Fix: name it omnivoice.compose.yml (outside the glob) and commit it for real, so 'make -C pmoves omnivoice-up' works without the operator hand-pasting from SPARK_DEPLOY.md. Repoints OMNIVOICE_COMPOSE to the new path. Service unchanged (omnivoice-server, :8002, GPU reservation, HF cache volume, profiles creator/voice, OMNIVOICE_PLATFORM arm64 hook for SPARK). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(omnivoice): default bind 0.0.0.0 so in-stack flute-gateway can reach it Codex P2: flute-gateway normalizes OMNIVOICE_URL 127.0.0.1 -> host.docker.internal (main.py:183), which on Linux/bridge Docker resolves to the host gateway interface, not loopback — so a 127.0.0.1-published OmniVoice port was unreachable from the flute-gateway container, breaking the default in-stack deployment unless every operator overrode the bind. Default to 0.0.0.0 (access gated by OMNIVOICE_TOKEN); operators on exposed nodes with no in-container consumer can still set OMNIVOICE_BIND=127.0.0.1. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…lines (#2402) The village-gate 3-policy fix (#2285) left only the USER/useradd/CMD tail (in the wrong order: USER before useradd) and deleted the entire build — FROM, torch install, requirements, server COPY, healthcheck — making 'no build stage in current context' the omnivoice-build/up failure. Restored the original 89-line deploy unit from #1845 and applied the policy the gate wanted PROPERLY: useradd before USER, cache/app ownership so the HF download can write, non-root at runtime. Found while standing up the set-not-preset voice vessels (OmniVoice = ref_audio catalog + instruct voice design). Co-authored-by: Mavis <Mavis@pmoves.local> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
1 participant
Summary
Turns the OmniVoice voice server (
pmoves/services/creator-operator/omnivoice_server.py)from a manual
python omnivoice_server.pyinto a managed fleet service for theSPARK node (NVIDIA DGX Spark, GB10 Grace-Blackwell, arm64 + CUDA, 128GB unified,
caps
[cuda, comfyui, browser, voice]).Files
pmoves/services/creator-operator/Dockerfile.omnivoicenvidia/cudaruntime base (CUDA_BASE_TAGARG). torch/torchaudio via ARG-driven index URL (TORCH_INDEX_URL, default cu128). GPU via the NVIDIA container runtime, not baked in. Binds0.0.0.0:8002,/healthzHEALTHCHECK, no secrets baked. Build context = service dir (noservices.commonimport).pmoves/Makefileomnivoice-build/omnivoice-up/omnivoice-downtargets driving the service-local compose under thevoiceprofile.pmoves/services/creator-operator/SPARK_DEPLOY.mdROCM_VALIDATION.md.SPARK arm64-CUDA wheel TODO
SPARK is arm64, so the stock x86_64 cu128 torch wheel does not apply — it needs the
arm64/sbsa CUDA wheel (CUDA 12.8+). The exact wheel tag / index URL is left as
TODO-confirm-on-node(not guessed); the Dockerfile install is ARG-driven(
TORCH_INDEX_URL/TORCH_SPEC) so the operator overrides it on the node after groundingnvidia-smi+uname -m. Mirrors howROCM_VALIDATION.mdhandles the unknown ROCm wheel.Compose file (operator action)
docker-compose*.ymlpaths are damage-control-protected (thecomposeKnown Road class,matched by basename — even service-local). The branch author could not write the
compose file in-session (the
KNOWN_ROADenv bypass is self-grant-denied), so thefull paste-ready
docker-compose.omnivoice.yml+ the operator Known-Road steps are inSPARK_DEPLOY.md § 3a, with an optional root-level fleet-compose integration in § 3c.
The compose YAML snippet is
yaml.safe_load-validated.Validate-on-SPARK scaffold (NOT GPU-tested)
There is no SPARK / arm64 / GPU in the authoring environment. The image was not
built and the server not run or GPU-tested. This is a scaffold to validate on SPARK.
A "do not route live voice to SPARK until these pass" gate is in the doc; the smoke harness
reuses
scripts/rocm_smoke.sh(node-agnostic) against the deployed:8002.🤖 Generated with Claude Code