recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

journal(2): scouted mumble (Q4.2) — first non-HTTP recipe; design = python sidecar probe on app overlay network for the TLS protocol test; enrollment plan recorded for next tick

Browse Source
This commit is contained in:
autonomic-bot
2026-05-29 07:47:42 +01:00
parent 426a953c2b
commit 7997b98935
1 changed files with 31 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
machine-docs/JOURNAL-2.md
View File

@ -714,3 +714,34 @@ bug fixed, two open issues (disk-blocker on upgrade tier [DEFERRED/operator]; fl
[BACKLOG, needs robustness work]). **Pivoting to lighter recipes for broad Phase-2 progress**;
lasuite-drive's OIDC robustness + upgrade-disk return later. Host left clean (all stacks torn down,
disk 65%, infra healthy).
---
## 2026-05-29 — Next unit scouted: mumble (Q4.2) — design for the first NON-HTTP recipe
Pivoted off heavy lasuite-drive to a lighter recipe. mumble: recipe.toml has NO deps, single light
service (mumblevoip/mumble-server:v1.6.870-0) → fast deploys, low disk (avoids the lasuite-drive
heaviness/flakiness). BUT it's the first non-HTTP recipe: raw Mumble protocol over TLS on TCP 64738
(+ UDP). Reference corpus `/srv/recipe-maintainer/recipe-info/mumble/tests/`: health_check.py (TCP
connect to 64738), mumble_connect.py (pure-stdlib TLS handshake: Version + auth-accepted +
ChannelState + ServerSync + welcome text — portable as-is), web_client.py (HTTPS web UI, needs
`compose.mumbleweb.yml` overlay).
**Reachability decision (the crux):** cc-ci's traefik is HTTP(S)-only; the recipe declares traefik
TCP/UDP router labels but cc-ci has no :64738 TCP entrypoint, and host→overlay-container-IP isn't
reliably routable. **Chosen approach: run the protocol probe from a throwaway `python:3-slim`
sidecar container attached to the app's overlay network**, connecting to the murmur service by its
swarm DNS name (`app`) on 64738. No traefik change, no host-port publish, no compose-overlay
selection needed — the harness already knows the stack/network name. This becomes a small reusable
harness primitive (`run probe container on app network`) for any future non-HTTP recipe. Record in
DECISIONS.md when implemented.
**Enrollment plan (next tick):** mirror-check mumble on recipe-maintainers (auto-mirror if absent per
plan §0b); `tests/mumble/recipe_meta.py` (no DEPS; HEALTH via the sidecar TCP probe, not HTTP —
needs a recipe_meta hook or a custom install overlay since the generic HTTP health check won't apply;
likely set CCCI_SKIP_GENERIC or provide a TCP-aware install overlay); port health_check +
mumble_connect as functional tests using the sidecar primitive; ≥2 specifics (protocol handshake +
channel-list presence beyond TCP health); PARITY.md; e2e (light/fast). web_client.py deferred unless
the mumbleweb overlay is enabled. Open question to resolve in code: how the generic install tier
(HTTP health) behaves for a non-HTTP recipe — may need a per-recipe "health kind = tcp" in
recipe_meta consumed by the generic harness.