Debug a failing relay end to end - inspect the kind cluster, relay logs and rendered coturn config, and run turnfleet-probe by hand. Use when a relay never forms, a probe fails, or an e2e case breaks.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Symptom first, then the narrowest check that can distinguish the candidates. The failure this project exists to remove is silent, so work from evidence, not from "the pod is Running".
kubectl --context kind-turnfleet get turnpools -A -o wide
kubectl --context kind-turnfleet -n <ns> get turnpool <pool> -o yaml
Read status.relays[]: ready, draining, relayAddress, portRange,
portsInUse/portsTotal, and lastProbe.{succeeded,message}. A relay that is
ready: false with a probe message is a data plane problem. A relay that is
missing from status.relays is a planner problem. kubectl --context kind-turnfleet describe turnpool <pool> shows the conditions:
Ready, ProbeSucceeded, CapacityPressure, AddressConflict, Degraded.
kubectl --context kind-turnfleet -n <ns> get secret <pool>-relay-config \
-o jsonpath='{.data.<relay>}' | base64 -d
The Secret carries one key per relay, named after its pod. Check the listening
address, --relay-ip/--external-ip, --min-port/--max-port, realm, and
that --static-auth-secret matches the Secret the issuer uses. If the config
looks right but the relay is not running, the pod is probably not on a labelled
relay node.
kubectl --context kind-turnfleet -n <ns> get pods -o wide | grep relay
kubectl --context kind-turnfleet -n <ns> logs <relay-pod> --tail=100
kubectl --context kind-turnfleet -n <ns> exec <relay-pod> -- \
curl -s localhost:9641/metrics | grep turn_total_allocations
A relay that started but cannot bind its range logs a bind error and exits:
that means another process on the node already owns those ports (see the
partitioning rules in docs/adr/0001-addressing-modes.md).
kubectl --context kind-turnfleet -n <ns> get secret <auth-secret> \
-o jsonpath='{.data.<key>}' | base64 -d > /tmp/turn-secret
bin/turnfleet-probe --uri "turn:<relayAddress>:<port>?transport=udp" \
--secret-file /tmp/turn-secret --expect-address <relayAddress> \
--expect-port-range <start>-<end> --json
A failure from inside the cluster isolates configuration from reachability.
What it cannot see is hairpin NAT and firewalls in front of the node, which is
why docs/capacity-model.md says the external vantage point is the
authoritative check. Run the same command from the host against the node
address to test the external path.
turnfleet_allocation_failures_total{code="508"} going up, with
CapacityPressure true, means the relay's range is genuinely exhausted and the
other relays are still serving. To reproduce it, allocate in a loop from a pion
client until the relay answers 508. The e2e saturation case does exactly this.
Never widen a range or restart a relay to make a symptom disappear without naming the cause. That is how the capacity illusion comes back.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add a new addressing mode to Turnfleet - implement Planner and Renderer, golden tests, an e2e case and an ADR. Use when a new way of assigning relay addresses or port ranges is needed.
The English summary is being prepared. Showing the original description.
Change the TURNPool API types safely - edit types and markers, regenerate, update webhooks, tests and docs. Use whenever a field is added, removed or re-marked in api/v1alpha1.
The English summary is being prepared. Showing the original description.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
The English summary is being prepared. Showing the original description.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
The English summary is being prepared. Showing the original description.
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
The English summary is being prepared. Showing the original description.
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
The English summary is being prepared. Showing the original description.