2 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	13cf9a30cb	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.	2026-08-21 20:53:32 -07:00
jcoffey-dev	b98f397221	Add sentry_alert_rule, the Terraform provider's second resource ... Confirmed with the project owner first: alerting's REST API has no PUT /rules/{id} at all -- confirmed down to rulestore.Store, which has Create/List/Get/Delete but no Update method to even wire one to, a real pre-existing gap in alerting's own API, not something new to this task. Decided to model sentry_alert_rule as create/destroy only rather than fake an in-place update via delete-then-recreate inside the resource: every attribute carries a RequiresReplace plan modifier, so a config change destroys and recreates the rule, surfacing in the plan output the real side effect that has (alert_state/delivery-log continuity resets) instead of hiding it. Adding a real PUT /rules/{id} to alerting would remove this constraint but is a change to a different module's REST API, out of scope here. internal/provider/client.go's new rule type and createRule/getRule/ deleteRule methods talk the exact same JSON contract sentryctl alerts apply already uses against alerting/internal/httpapi. GET /rules/{id} actually returns rulestore.RuleWithState (Rule's fields promoted via anonymous embedding, plus a "state" object) -- the local rule type has no field for "state" by design, and a new client test proves that extra key doesn't break parsing. alerting is a genuinely separate service from api (its own base URL), so this needed the provider to talk to more than one Sentry service for the first time: providerData now wraps two *client instances (api, alerting), with a new alerting_endpoint provider attribute defaulting the same way sentryctl's --alerting-api/$SENTRYCTL_ALERTING_API_URL does. dashboardResource's Configure updated to pull .api out of the new wrapper type instead of a bare *client. Schema mirrors sentry_dashboard's established pattern: comparator/ threshold_value/renotify_interval_minutes stay nullable (only meaningful for threshold-condition rules), enabled/for_minutes/query_language are Optional+Computed with a Terraform-side default matching the API's own default (true/0/"") rather than leaving the API as sole source of truth the way dashboard's default_earliest/default_latest deliberately do -- these three have no *pointer* type in the API's Rule struct, so their "default when omitted" is unconditional, not a real API-side default that could drift independently. Verified: client tests are real httptest.Server round trips (same pattern as sentry_dashboard's). Schema validation needs no Terraform binary. TestAccAlertRuleResource_basic is a real acceptance test, skip-gated by TF_ACC same as the dashboard one, including a plancheck.ExpectResourceAction assertion that a config change actually plans destroy-then-create -- the concrete, checked version of the "create/destroy only" design decision, not just a comment. Not run against a live stack in this environment, same disclosed gap as everything else Docker-gated in this repo.	2026-08-15 00:15:45 -07:00