Skip to content

feat(netbird): support external relay config and verify relay in e2e (#83)#87

Open
mikkeldamsgaard wants to merge 1 commit intomainfrom
feat/issue-83-relay-config
Open

feat(netbird): support external relay config and verify relay in e2e (#83)#87
mikkeldamsgaard wants to merge 1 commit intomainfrom
feat/issue-83-relay-config

Conversation

@mikkeldamsgaard
Copy link
Copy Markdown
Contributor

Summary

  • Add server.config.relays.{addresses, credentialsTTL} and a dedicated server.secrets.relaySecret so peers can be pointed at an external relay deployment when the public relay hostname differs from the management hostname. When relays.addresses is empty (default), the embedded relay continues to run and reuse authSecret exactly as before — no behavior change for existing installs.
  • Extend ci/scripts/netbird/e2e.sh to run netbird status --detail inside a registered peer pod and assert the relay shows is Available, so the exact symptom from Relay server not working #83 ("relay client not connected") becomes a CI failure rather than a silent runtime regression.
  • Helm-unittest: 14 new cases covering the relay block rendering, RELAY_SECRET env wiring (external secret vs. auto-generated), and the auto-generated Secret's relaySecret key.

Refs #83.

Test plan

  • helm lint charts/netbird passes
  • helm unittest charts/netbird — 247 / 247 pass, 11 snapshots intact
  • make e2e-sqlite passes locally end-to-end (kind cluster up → chart installed with PAT seed → 2 peer pods registered with accessible_peers=1Relay is Available confirmed inside netbird-peer-1)
  • CI green

🤖 Generated with Claude Code

…83)

Add `server.config.relays.{addresses, credentialsTTL}` and a dedicated
`server.secrets.relaySecret` reference so users can point peers at an
external relay deployment when the public relay hostname differs from
the management hostname. When `relays.addresses` is empty (default), the
embedded relay continues to run and reuse `authSecret` exactly as before.

The chart's e2e script now runs `netbird status --detail` inside a
registered peer pod and asserts the relay shows `is Available`, so the
exact symptom in #83 ("relay client not connected") becomes a CI
failure rather than a silent runtime regression.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant