Files
cairnobs/transport/README.md
T
jcoffey-dev c920e0f2c4 Finish the Cairn OBS rename through services, docs, and assets
The rename commit before this one covered module paths and the obvious
user-facing strings; this is the rest of it -- the places where "sentry"
was a default value, a filename, or a picture rather than a word in a
sentence.

Defaults that changed: CLICKHOUSE_DATABASE (sentry -> cairnobs),
POSTGRES_DATABASE (sentry_metadata -> cairnobs_metadata), and
POSTGRES_USERNAME (sentry -> cairnobs), across api/alerting/ingest and
the enterprise binaries, plus the compose files and migrate scripts that
create those objects. These are *defaults*, so a deployment that sets
them explicitly is unaffected -- but any deployment relying on the old
defaults must have its environment updated before it picks this up, or
it will come up pointing at a database that doesn't exist.

Also: the light-mode logo variants (the dark ones existed alone, so the
landing page and sidebar rendered a dark mark on a light background),
regenerated favicons, and the docs/README/threat-model prose that still
said Sentry.
2026-08-22 16:12:08 -07:00

1.3 KiB

transport

Redpanda for local development, plus the script that provisions the topic /ingest depends on.

Topic naming contract

ingest defaults to REDPANDA_TOPIC=cairnobs.logs.raw (see /ingest/internal/config). provision-topics.sh defaults to the same name. These aren't wired together automatically — if you change one, change the other, or override REDPANDA_TOPIC consistently wherever both are invoked.

Running standalone

docker compose up -d
./provision-topics.sh   # defaults (localhost:9092 / localhost:9644) match this compose file

Two separate addresses matter here, confirmed by actually running this against a live Redpanda container: rpk cluster health talks to the Admin API (REDPANDA_ADMIN_HOSTS, port 9644), while rpk topic ... talks to the Kafka API (REDPANDA_BROKERS, port 9092) — and neither accepts a --brokers flag directly, both need -X admin.hosts=... / -X brokers=.... Get this wrong and it doesn't error loudly: it just retries the health check forever without ever reporting why.

In the full stack

The root-level docker-compose.yml builds this directory's Dockerfile (FROM the Redpanda image itself, so rpk is already present) as a one-shot init service that runs after Redpanda reports healthy. See /docs/phase-0-runbook.md.