cairnobs

152 Commits 1 Branch 0 Tags

3 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
jcoffey-dev	49dd050689	Start the Terraform provider: sentry_dashboard, the first resource CLAUDE.md names the Terraform provider a first-class deliverable alongside sentryctl ("CLI and Terraform provider are first-class, not afterthoughts"), but no phase before this one had actually built any of it -- no terraform/ directory existed. This is a first slice, not a finished provider: one resource, scoped and confirmed with the project owner before starting (a new pinned external dependency and an architectural decision not covered in /docs/architecture.md are both things CLAUDE.md's own "When in doubt" section says to ask about). New Go module (terraform/, github.com/sentry/sentry/terraform) built on HashiCorp's terraform-plugin-framework -- the actively-developed library, not the legacy SDKv2, since there's no existing provider code to migrate and no reason to start new on the framework HashiCorp itself steers people away from. internal/provider/client.go talks the exact same JSON contract sentryctl's "dashboards apply" and web's Export JSON button already use against api/dashboards.Handler (POST/GET/PUT/DELETE /dashboards[/{id}]) -- cli/README.md already named this "the seed of a future Terraform provider: one JSON contract, multiple callers," this is that third caller, not a new contract invented for Terraform's sake. sentry_dashboard's schema deliberately leaves default_earliest/ default_latest Optional+Computed with no Terraform-side static default, even though the API defaults them to "-1h"/"now" when empty -- letting the API stay the one source of truth for what "unset" means rather than duplicating that default in two places that could drift. tenant_id is Computed-only, matching api/dashboards.Handler's own tenantID() doc comment that a client-supplied value is always overridden server-side. Panels are not modeled by this resource -- a genuinely separate resource shape (own lifecycle, own endpoints, own validation needs), scoped out deliberately, not an oversight. Alert rules, notification targets, and tenant/RBAC resources are the same: real, disclosed future work, not attempted in this pass. See terraform/README.md for the full accounting. Verified: client_test.go runs real HTTP round trips against httptest. Server (request construction, response parsing, the 404-vs-other-error distinction Read/Delete need for Terraform's out-of-band-deletion convention) -- same pattern cli/cmd/sentryctl's own tests already use against the same api/dashboards endpoints. provider_test.go validates both schemas are internally well-formed without needing a Terraform binary. dashboard_resource_test.go's TestAccDashboardResource_basic is a real acceptance test (terraform-plugin-testing), skip-gated by TF_ACC=1 per that framework's own convention -- even with TF_ACC set it would still need a live api service (Postgres+ClickHouse) to apply against, which this environment has no Docker access to bring up, so it has not actually run here, same disclosed gap as every other live-infra test in this repo.	2026-08-15 00:06:26 -07:00

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

jcoffey-dev

49dd050689

Start the Terraform provider: sentry_dashboard, the first resource

CLAUDE.md names the Terraform provider a first-class deliverable
alongside sentryctl ("CLI and Terraform provider are first-class, not
afterthoughts"), but no phase before this one had actually built any of
it -- no terraform/ directory existed. This is a first slice, not a
finished provider: one resource, scoped and confirmed with the project
owner before starting (a new pinned external dependency and an
architectural decision not covered in /docs/architecture.md are both
things CLAUDE.md's own "When in doubt" section says to ask about).

New Go module (terraform/, github.com/sentry/sentry/terraform) built on
HashiCorp's terraform-plugin-framework -- the actively-developed
library, not the legacy SDKv2, since there's no existing provider code
to migrate and no reason to start new on the framework HashiCorp itself
steers people away from.

internal/provider/client.go talks the exact same JSON contract
sentryctl's "dashboards apply" and web's Export JSON button already use
against api/dashboards.Handler (POST/GET/PUT/DELETE /dashboards[/{id}]) --
cli/README.md already named this "the seed of a future Terraform
provider: one JSON contract, multiple callers," this is that third
caller, not a new contract invented for Terraform's sake.

sentry_dashboard's schema deliberately leaves default_earliest/
default_latest Optional+Computed with no Terraform-side static default,
even though the API defaults them to "-1h"/"now" when empty -- letting
the API stay the one source of truth for what "unset" means rather than
duplicating that default in two places that could drift. tenant_id is
Computed-only, matching api/dashboards.Handler's own tenantID() doc
comment that a client-supplied value is always overridden server-side.

Panels are not modeled by this resource -- a genuinely separate resource
shape (own lifecycle, own endpoints, own validation needs), scoped out
deliberately, not an oversight. Alert rules, notification targets, and
tenant/RBAC resources are the same: real, disclosed future work, not
attempted in this pass. See terraform/README.md for the full accounting.

Verified: client_test.go runs real HTTP round trips against httptest.
Server (request construction, response parsing, the 404-vs-other-error
distinction Read/Delete need for Terraform's out-of-band-deletion
convention) -- same pattern cli/cmd/sentryctl's own tests already use
against the same api/dashboards endpoints. provider_test.go validates
both schemas are internally well-formed without needing a Terraform
binary. dashboard_resource_test.go's TestAccDashboardResource_basic is a
real acceptance test (terraform-plugin-testing), skip-gated by TF_ACC=1
per that framework's own convention -- even with TF_ACC set it would
still need a live api service (Postgres+ClickHouse) to apply against,
which this environment has no Docker access to bring up, so it has not
actually run here, same disclosed gap as every other live-infra test in
this repo.

2026-08-15 00:06:26 -07:00