Rebrand: Sentry -> Cairn OBS

Full rebrand across cosmetic branding, code identifiers, and
infrastructure/data-plane naming, using the supplied Cairn OBS logo
package. Cosmetic: favicon/logo swap (also closes a stale license-audit
finding -- the old favicon was SvelteKit's unreplaced scaffold logo),
new centered welcome landing page, larger/legible sidebar logo, page
titles, CLAUDE.md/README/docs prose.

Code identifiers: Go module path github.com/sentry/sentry ->
github.com/cairnobs/cairnobs across all 13 modules and ~91 files (protoc
regenerated); Rust crates sentry-agent/sentry-parser/sentry-search ->
cairnobs-*; CLI sentryctl -> cairnobsctl; Terraform provider fully
renamed (sentry_dashboard etc. -> cairnobs_dashboard, provider type,
env vars); every session/auth cookie name; agent config paths and
Windows service identity.

Deliberately preserved: the gRPC wire protocol's protobuf packages
(sentry.logs.v1, sentry.agent.v1) and their Go import directory
(proto/sentry/...) -- renaming the wire-level package would break every
currently-deployed agent binary (confirmed two real hosts, including
mail.inbuxa.com, are actively streaming through this exact contract)
until rebuilt and redeployed in lockstep with an ingest cutover. Only
the Go module path wrapping the generated code changes.

Infrastructure: every docker-compose container name (root and three
component-level compose files); the Helm chart (directory, Chart.yaml,
named-template helpers, all templates, values.yaml image repos);
Kubernetes Operator (CRD group sentry.io -> cairnobs.io, both CRD YAML
files, Go identifiers, RBAC markers); the coupled enterprise/tenantcrd
package. Caught and fixed real path-coupling bugs along the way: the
Helm chart's search/ingest volume mounts and the dev-only-credential
detection constant vs. docker-compose.yml's literal values had to move
together or a security warning would have silently stopped firing.

Data plane: Postgres database sentry_metadata -> cairnobs_metadata and
role sentry -> cairnobs; ClickHouse database sentry -> cairnobs; Kafka
topic sentry.logs.raw -> cairnobs.logs.raw and its consumer groups.
Source-level defaults, docker-compose.yml, and every migrate.sh/
provision script default updated together; already-applied migration
files left untouched per this repo's immutable-migration convention.

Verified at every layer: all 13 Go modules build/vet/test clean, both
Rust workspaces (agent, search) build/clippy/test clean, npm run check/
build clean, docker compose config validates on all four compose files.
Live-verified against a real docker stack multiple times through this
work, including a final fresh-volume run confirming the actual renamed
Postgres database/role, ClickHouse database, and Kafka topic all work
end to end with a real login and query, zero console errors.
This commit is contained in:
2026-08-21 20:53:32 -07:00
parent 9e21ea17bb
commit 13cf9a30cb
291 changed files with 1565 additions and 1441 deletions
+15 -14
View File
@@ -28,7 +28,7 @@ like BSL/SSPL, anything with a field-of-use or non-compete restriction).
1. **Inventory** every dependency, direct and transitive, in every
language ecosystem present in the repo:
- **Rust** (`agent` workspace: `sentry-agent`, `sentry-parser`;
- **Rust** (`agent` workspace: `cairnobs-agent`, `cairnobs-parser`;
`search`): `cargo-deny` (`cargo deny list --format tsv`), installed
fresh for this audit (`cargo install cargo-deny --locked`).
- **Go** (`api`, `ingest`, `alerting`, `enterprise`,
@@ -191,18 +191,18 @@ Key facts, verified against primary sources:
plaintext core Kafka-protocol functionality — no RCL-gated enterprise
features, no tiered storage, no SASL/RBAC — squarely within the
permitted grant as an internal transport layer.
- **No AGPL linking/compatibility issue.** Sentry never links against
- **No AGPL linking/compatibility issue.** Cairn OBS never links against
Redpanda's code; it's consumed purely over the Kafka wire protocol, the
same relationship as ClickHouse and Postgres. AGPLv3's copyleft
doesn't reach across a network-protocol boundary to unrelated,
separately-licensed software you merely talk to.
- **The genuinely open question**: Phase 6 relicenses `enterprise/` to
AGPLv3 specifically so that anyone, including competitors, can legally
self-host or fork Sentry — including offering it as a network service,
self-host or fork Cairn OBS — including offering it as a network service,
per AGPLv3's own terms. If a third party does that using the bundled
`docker-compose.yml` (which pulls this BSL-licensed Redpanda image),
does *their* deployment trip BSL's Streaming-or-Queuing-Service
restriction? Sentry's ingest pipeline creates fixed internal topics,
restriction? Cairn OBS's ingest pipeline creates fixed internal topics,
not per-end-user topics exposed for direct third-party production or
consumption — so this is very likely **not** a Streaming-or-Queuing-Service
under BSL's own definition. But this is a business/redistribution
@@ -211,7 +211,7 @@ Key facts, verified against primary sources:
### Remediation options (recorded per task 4's requirement)
1. **Accept as-is.** Document the reasoning above; Sentry's own use is
1. **Accept as-is.** Document the reasoning above; Cairn OBS's own use is
clearly within BSL's permitted grant, and the third-party-SaaS
scenario is a reasonable-but-unverified reading, not a known
violation. Lowest effort, zero functional change.
@@ -241,22 +241,23 @@ deployment change was made as a result — Redpanda stays pinned at
v24.2.7 in `docker-compose.yml`/`transport/`, under BSL 1.1, as a
disclosed and accepted risk rather than an unresolved one. This
decision should be revisited if the project's redistribution posture
changes materially (e.g. an official hosted/managed offering of Sentry
itself, which would make the third-party-SaaS reading in this section
Sentry's *own* situation rather than a hypothetical third party's).
changes materially (e.g. an official hosted/managed offering of Cairn
OBS itself, which would make the third-party-SaaS reading in this section
Cairn OBS's *own* situation rather than a hypothetical third party's).
## Non-license finding: `favicon.svg`
`web/src/lib/assets/favicon.svg` is SvelteKit's own default project
`web/src/lib/assets/favicon.svg` was SvelteKit's own default project
scaffold logo (`<title>svelte-logo</title>` — the `sv create`/`create-svelte`
starter icon), never replaced with an original mark during Phase 5's
redesign. Not a license-compatibility blocker — Svelte's own project
assets are MIT-licensed — but it's unauthored, third-party-branded
assets are MIT-licensed — but it was unauthored, third-party-branded
content shipping as this product's own favicon, caught by the same
"grep for anything that looks copied" pass this audit's task 1 asked
for. Recorded as an action item (replace with an original Sentry mark),
not a compliance blocker; not fixed here since it's a design task outside
this phase's scope, not a licensing one.
for. Recorded as an action item (replace with an original mark), not a
compliance blocker at the time; **resolved as part of the Sentry → Cairn
OBS rebrand**, which replaced it with the real Cairn OBS mark from the
project's own logo package.
## Own license declarations (task 5)
@@ -347,7 +348,7 @@ assumed.
- Final repo-wide grep for `commercial` confirms every remaining
occurrence is one of the above corrections (explicitly framed as
historical/superseded), not a live claim. **No file in the repo claims
a license other than AGPLv3** for Sentry's own code, as of this audit.
a license other than AGPLv3** for Cairn OBS's own code, as of this audit.
## Ongoing enforcement (task 7)
+1 -1
View File
@@ -97,7 +97,7 @@ this project uses it. **Decision recorded 2026-08-16: accept as-is** —
see the audit report's Redpanda section for the full reasoning, the
other two remediation options that were considered and not chosen, and
the condition under which this decision should be revisited (an
official hosted/managed Sentry offering). A future change to Redpanda's
official hosted/managed Cairn OBS offering). A future change to Redpanda's
license, or to this project's own redistribution posture, should trigger
re-review, not silently ride on this entry.