Follow-up to #43. Observo was named as the reason to build a mesh rather than a point-to-point integration ("Observo sending notifications via Notifier"), so the path exists in principle — but nothing is provisioned for it yet.
Three pieces, none of which exist today:
1. ACL rule
observo-primary is a user-owned node, not tagged (gregoryfoster@, 100.105.63.31). Observo's own ACL reaches it via a hosts entry rather than a tag, so the rule granting it notifier access must use the same form — tag:observo-* will not match it:
Dev endpoint (:9001) only if Observo actually wants one; it is a separate grant.
2. Tenant + API key
Observo needs its own tenant, not watcher's. scripts/seed_tenant.py provisions it; production requires NOTIFIER_ALLOW_PROD_DB=1, which lives in the systemd unit.
Mark the key production for the real path and mint a separate development key if Observo wants :9001 — production refuses development-marked keys with 403 by design (#24), and that refusal is the feature.
3. Credential placement on Observo's side
Worth stating explicitly because notifier's own history is what makes it matter. Watcher learned this twice: watcher#277 gated the client behind a unit-only flag after a prod-sourced shell could dispatch for real, and watcher#278 then moved the credential out of the shell-sourced env file entirely — by which point notifier's audit had already found ~1289 watcher fixture notifications delivered to the real Slack and Mailgun channels.
Observo should land on the same shape from the start rather than rediscovering it: credential in a unit-only EnvironmentFile, never in a file load-env-style tooling sources into every agent shell and pytest run. Observo already applies exactly this pattern to CO_OBSERVO_TAILSCALE_* and CO_OBSERVO_EXE_API_TOKEN, so it is a convention it already holds — just not yet for a notifier key it does not have.
Not blocking
Nothing in #43 depends on this, and notifier serves watcher correctly without it. File-and-forget until Observo actually wants to dispatch.
Follow-up to #43. Observo was named as the reason to build a mesh rather than a point-to-point integration ("Observo sending notifications via Notifier"), so the path exists in principle — but nothing is provisioned for it yet.
Three pieces, none of which exist today:
1. ACL rule
observo-primaryis a user-owned node, not tagged (gregoryfoster@,100.105.63.31). Observo's own ACL reaches it via ahostsentry rather than a tag, so the rule granting it notifier access must use the same form —tag:observo-*will not match it:Dev endpoint (
:9001) only if Observo actually wants one; it is a separate grant.2. Tenant + API key
Observo needs its own tenant, not watcher's.
scripts/seed_tenant.pyprovisions it; production requiresNOTIFIER_ALLOW_PROD_DB=1, which lives in the systemd unit.Mark the key
productionfor the real path and mint a separatedevelopmentkey if Observo wants:9001— production refusesdevelopment-marked keys with 403 by design (#24), and that refusal is the feature.3. Credential placement on Observo's side
Worth stating explicitly because notifier's own history is what makes it matter. Watcher learned this twice: watcher#277 gated the client behind a unit-only flag after a prod-sourced shell could dispatch for real, and watcher#278 then moved the credential out of the shell-sourced env file entirely — by which point notifier's audit had already found ~1289 watcher fixture notifications delivered to the real Slack and Mailgun channels.
Observo should land on the same shape from the start rather than rediscovering it: credential in a unit-only
EnvironmentFile, never in a fileload-env-style tooling sources into every agent shell and pytest run. Observo already applies exactly this pattern toCO_OBSERVO_TAILSCALE_*andCO_OBSERVO_EXE_API_TOKEN, so it is a convention it already holds — just not yet for a notifier key it does not have.Not blocking
Nothing in #43 depends on this, and notifier serves watcher correctly without it. File-and-forget until Observo actually wants to dispatch.