Enable host-local SigNoz on the local mac (host-scoped opt-in) #437

New issue

Closed

opened 2026-07-02 10:04:01 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-02 10:04:01 +00:00

Owner

Goal

Turn on the host-local SigNoz backend (added in #435) for the operator's local mac so it actually runs, without turning it on fleet-wide. It is signoz_enabled: false everywhere today (ansible/roles/signoz/defaults/main.yml and ansible/inventory/group_vars/mac.yml:145), and ansible/inventory/host_vars/ is empty, so nothing runs it.

Inventory wrinkle to resolve first

docs/signoz-local.md says to opt in via a specific mac's host_vars (not group_vars, because the stack is heavy). But macs converge via the LOCAL leg against localhost (ansible/playbooks/sync.yml group_by classifies Darwin -> mac, and ward exec ansible-sync local=1 runs the local connection). So host_vars/localhost.yml would apply to EVERY mac's local leg, not one specific mac. Resolve how to scope this to a single mac (e.g. keying host_vars on the real hostname, a documented convention, or accepting group-level enable if there is effectively one mac). Capture the chosen approach in docs/signoz-local.md.

Work (this repo)

Make the repo change that enables SigNoz for the operator's local mac using the resolved scoping approach.
Keep it off for any other mac.

Note on bring-up

A headless container cannot converge the operator's physical mac. This issue's deliverable is the repo change only. The operator runs ward exec ansible-sync local=1 on the mac to actually bring the stack up, then applies retention in the SigNoz UI (Settings -> Retention, 7d per the role vars).

Depends on / pairs with the agent-proxy OTLP wiring issue. Context: #435, docs/signoz-local.md.

## Goal Turn on the host-local SigNoz backend (added in #435) for the operator's local mac so it actually runs, without turning it on fleet-wide. It is `signoz_enabled: false` everywhere today (`ansible/roles/signoz/defaults/main.yml` and `ansible/inventory/group_vars/mac.yml:145`), and `ansible/inventory/host_vars/` is empty, so nothing runs it. ## Inventory wrinkle to resolve first `docs/signoz-local.md` says to opt in via a specific mac's `host_vars` (not `group_vars`, because the stack is heavy). But macs converge via the LOCAL leg against `localhost` (`ansible/playbooks/sync.yml` group_by classifies Darwin -> `mac`, and `ward exec ansible-sync local=1` runs the local connection). So `host_vars/localhost.yml` would apply to EVERY mac's local leg, not one specific mac. Resolve how to scope this to a single mac (e.g. keying host_vars on the real hostname, a documented convention, or accepting group-level enable if there is effectively one mac). Capture the chosen approach in `docs/signoz-local.md`. ## Work (this repo) 1. Make the repo change that enables SigNoz for the operator's local mac using the resolved scoping approach. 2. Keep it off for any other mac. ## Note on bring-up A headless container cannot converge the operator's physical mac. This issue's deliverable is the repo change only. The operator runs `ward exec ansible-sync local=1` on the mac to actually bring the stack up, then applies retention in the SigNoz UI (Settings -> Retention, 7d per the role vars). Depends on / pairs with the agent-proxy OTLP wiring issue. Context: #435, `docs/signoz-local.md`.

coilyco-ops commented

2026-07-02 10:04:17 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-infrastructure-437 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T10:04:15Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-infrastructure-437` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T10:04:15Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 10:14:29 +00:00

feat(ansible): enable host-local SigNoz on the operator's mac (closes #437)

coilysiren closed this issue

2026-07-02 10:14:29 +00:00

coilysiren referenced this issue from a commit

2026-07-02 10:14:29 +00:00

Merge issue-437: enable host-local SigNoz on the operator's mac (closes #437)

coilysiren commented

2026-07-02 10:15:11 +00:00

Author

Owner

WARD-OUTCOME: done - group_vars/mac.yml now enables host-local SigNoz on the operator's mac (kais-macbook-pro-2) via a hostname-fact gate; docs and defaults updated, CI green on main.

The interesting part of this one was entirely in the framing, not the diff. The actual enable is a two-line change, but the issue's real ask was to resolve why the documented "opt in via host_vars" advice is a trap: every mac converges over the localhost local connection, so inventory_hostname is always localhost and any host_vars/localhost.yml would light up every mac at once. Gating signoz_enabled on the real ansible_facts['hostname'] (the same trick ser8-bootstrap already uses) was the clean way out, and the reservation comment handed me the hostname for free.

What fought back was the doc-size pre-commit cap (80 lines / 4000 chars) - signoz-local.md was already near the ceiling, so I split the scoping rationale into its own signoz-scoping.md and spent a few rounds shaving prose. Then issue-436 landed on main mid-flight and collided in the same doc's "What the proxy uses" section; I kept 436's container-aware version (host.docker.internal, not localhost) and re-trimmed to fit.

Fairly confident: the regex/.local/case handling is verified against the likely hostname spellings, and CI is green. The one thing I can't verify from a headless container is the exact casing macOS reports for the hostname fact - the case-insensitive, .local-stripping match should cover it, but the real proof is the operator running ward exec ansible-sync local=1 on the mac and seeing the stack come up. No follow-up worth filing unless that bring-up surprises us.

WARD-OUTCOME: done - group_vars/mac.yml now enables host-local SigNoz on the operator's mac (kais-macbook-pro-2) via a hostname-fact gate; docs and defaults updated, CI green on main. The interesting part of this one was entirely in the framing, not the diff. The actual enable is a two-line change, but the issue's real ask was to resolve why the documented "opt in via host_vars" advice is a trap: every mac converges over the localhost local connection, so inventory_hostname is always `localhost` and any host_vars/localhost.yml would light up every mac at once. Gating `signoz_enabled` on the real `ansible_facts['hostname']` (the same trick ser8-bootstrap already uses) was the clean way out, and the reservation comment handed me the hostname for free. What fought back was the doc-size pre-commit cap (80 lines / 4000 chars) - signoz-local.md was already near the ceiling, so I split the scoping rationale into its own signoz-scoping.md and spent a few rounds shaving prose. Then issue-436 landed on main mid-flight and collided in the same doc's "What the proxy uses" section; I kept 436's container-aware version (host.docker.internal, not localhost) and re-trimmed to fit. Fairly confident: the regex/`.local`/case handling is verified against the likely hostname spellings, and CI is green. The one thing I can't verify from a headless container is the exact casing macOS reports for the hostname fact - the case-insensitive, `.local`-stripping match should cover it, but the real proof is the operator running `ward exec ansible-sync local=1` on the mac and seeing the stack come up. No follow-up worth filing unless that bring-up surprises us.

coilyco-ops referenced this issue

2026-07-10 11:40:04 +00:00

Forgejo CI runner fails all pull_request gate jobs before checkout (0s) - blocks every aos/ward PR merge #536

coilyco-ops referenced this issue

2026-07-10 16:54:55 +00:00

Post-reboot recovery incomplete: Forgejo Actions runners + DNS/tailnet degraded on kai-server, landing-blocking fleet burndown #538