jcoffey-dev
823f5d48d1
Closes a gap named across CLAUDE.md/docs/architecture.md/deploy/README.md
since early Phase 4: the operator's Tenant CRD and -provision-tenant
were two disconnected mechanisms. The operator's reconciler generated a
K8s Secret with a locally-generated random password that authenticated
against nothing (nothing ever called ClickHouse to create a matching
user), and unconditionally claimed status.phase=Active the moment a
Tenant object existed -- actively misleading, not just incomplete.
Two unification shapes were considered (surfaced to the user via
AskUserQuestion, given the real difference in blast radius): the
operator's reconcile loop becoming a second real actor (new Postgres +
ClickHouse admin credentials flowing into the K8s controller, plus real
reconcile-loop idempotency/retry design for an inherently one-shot
external side effect), or keeping -provision-tenant as the sole real
actor and having it also sync its result into the CRD. Went with the
lighter option.
enterprise/internal/tenantcrd (new): a Syncer using the K8s dynamic
client (unstructured.Unstructured + a GroupVersionResource, not
deploy/operator's typed Tenant struct -- avoids a cross-module Go
dependency between two independently-versioned modules for one type).
Upserts the Tenant object, creates/updates a Secret with the *real*
ClickHouse credentials owned by that Tenant via an OwnerReference, then
patches status.{clickHouseDatabaseName,clickHouseSecretRef,
tantivyIndexPath}. Idempotent and safe to retry: never rotates a
credential across a re-sync, never overwrites a pre-existing
spec.displayName a human/GitOps process set.
cmd/enterprise-api/main.go's runProvisionTenant calls Sync when
TENANT_CRD_NAMESPACE is set (empty = no-op, same shape as every other
optional dependency in this codebase). Its "already active" refusal is
now split: ClickHouse re-provisioning is still refused (rotating a live
credential would break every open connection for no benefit), but CR
sync alone is now retryable using the credentials already on file in
rbacstore -- needed for retrying a previously-failed sync, or
backfilling CR sync for a tenant provisioned before this existed.
deploy/operator's reconciler rewritten to match: it never claims
PhaseActive on its own initiative anymore, only once
status.ClickHouseDatabaseName is non-empty (the field -provision-tenant,
and only -provision-tenant, sets). Phase is now a pure function of
{spec.suspended, status.ClickHouseDatabaseName != ""} recomputed every
reconcile, not toggled in place -- fixes a related bug the old code
would have hit once suspension was involved: un-suspending an
already-provisioned tenant needs to return straight to Active, which
isn't derivable from "last observed phase was Suspended" alone. The
reconciler no longer creates or manages any Secret, dropped its
`secrets` RBAC grant entirely, and gained zero new dependencies.
Helm chart: enterprise-api gets its own ServiceAccount/Role/RoleBinding
(get/list/create tenants, get/update/patch tenants/status, get/create/
update secrets -- least-privilege, scoped to the release namespace, not
a ClusterRole) and a TENANT_CRD_NAMESPACE env var, both gated on
tenantOperator.enabled. tenant-operator's ClusterRole loses the
secrets grant it no longer needs.
Verified in this environment: enterprise/internal/tenantcrd's tests run
against k8s.io/client-go's fake dynamic + typed clientsets (real client
library, fake transport, no cluster needed); deploy/operator's rewritten
tenant_controller_test.go runs against controller-runtime's fake
client, including new regression tests for the "must not claim Active
without confirmation" and "un-suspending returns to Active, not
Provisioning" properties; helm template + parsing the rendered YAML
confirms the RBAC split renders exactly as designed under both
tenantOperator.enabled=true/false. Not verified: an actual
-provision-tenant run against a real cluster with the operator watching
(no live cluster in this environment, same disclosed limitation as the
rest of /deploy). Docs updated in lockstep: CLAUDE.md, docs/architecture.md,
deploy/README.md, deploy/helm/sentry/README.md (including a corrected
"Trying the two-tenant example" walkthrough), phase-4-runbook.md (new
§11), enterprise/README.md. Also fixed two unrelated stale claims found
along the way: docs/architecture.md still said docker-compose.yml ran
plain api unconditionally (fixed in an earlier commit, doc not updated
then), and enterprise-api's own main.go doc comment still said Helm/
docker-compose wiring wasn't built yet.
197 lines
7.0 KiB
YAML
197 lines
7.0 KiB
YAML
# Default values for the sentry chart. See deploy/helm/sentry/README.md
|
|
# for the multi-tenant-specific values (enterprise.*, tenants) and what
|
|
# "multi-tenant-aware" does and doesn't mean at this layer.
|
|
#
|
|
# Image repositories default to locally-built tags matching each
|
|
# service's docker-compose.yml container_name, minus the "sentry-"
|
|
# container_name prefix duplication -- push these to a registry this
|
|
# cluster can actually pull from before installing; this chart never
|
|
# builds images itself (same division of labor as docker-compose.yml:
|
|
# `docker compose build` vs. `docker compose up`).
|
|
|
|
global:
|
|
imagePullPolicy: IfNotPresent
|
|
|
|
redpanda:
|
|
image:
|
|
repository: docker.redpanda.com/redpandadata/redpanda
|
|
tag: v24.2.7
|
|
persistence:
|
|
size: 10Gi
|
|
resources: {}
|
|
# Built from ./transport (docker-compose.yml's redpanda-provision
|
|
# service) -- the one-shot topic-creation Job below.
|
|
provisionImage:
|
|
repository: sentry-redpanda-provision
|
|
tag: latest
|
|
|
|
clickhouse:
|
|
image:
|
|
repository: clickhouse/clickhouse-server
|
|
tag: "24.8"
|
|
persistence:
|
|
size: 20Gi
|
|
resources: {}
|
|
# Leave empty to auto-generate and persist across upgrades -- see
|
|
# templates/secrets.yaml's stableSecretValue helper.
|
|
password: ""
|
|
# Built from ./storage (docker-compose.yml's clickhouse-migrate
|
|
# service) -- the one-shot schema-migration Job.
|
|
migrateImage:
|
|
repository: sentry-clickhouse-migrate
|
|
tag: latest
|
|
|
|
postgres:
|
|
image:
|
|
repository: postgres
|
|
tag: 16-alpine
|
|
persistence:
|
|
size: 10Gi
|
|
resources: {}
|
|
password: ""
|
|
auditWriterPassword: ""
|
|
# Built from ./metadata (docker-compose.yml's metadata-migrate
|
|
# service) -- the one-shot schema-migration Job.
|
|
migrateImage:
|
|
repository: sentry-metadata-migrate
|
|
tag: latest
|
|
|
|
ingest:
|
|
image:
|
|
repository: sentry-ingest
|
|
tag: latest
|
|
replicas: 1
|
|
resources: {}
|
|
# mTLS server cert/key/CA -- see hack/dev-certs/generate.sh for the
|
|
# dev equivalent of what this Secret must contain
|
|
# (server.pem/server-key.pem/ca.pem) in a real deployment. Unlike
|
|
# docker-compose.yml's bind-mounted ./hack/dev-certs/out, a cluster
|
|
# deployment supplies this as a real Secret -- named here, not
|
|
# generated by this chart (cert issuance is out of scope, same
|
|
# "boring, well-understood" preference as everywhere else in this
|
|
# repo -- use cert-manager or an equivalent, don't hand-roll it here).
|
|
tlsSecretName: ""
|
|
|
|
search:
|
|
image:
|
|
repository: sentry-search
|
|
tag: latest
|
|
# Pinned to 1: search consumes the same Redpanda topic ingest's
|
|
# consumer does with its own offset tracking (see search/README.md).
|
|
# A second replica would form a second, independent consumer instance
|
|
# against the same partitions with no coordination -- correctness,
|
|
# not just resource waste, is the reason this isn't a `replicas` knob
|
|
# yet. Matches CLAUDE.md's Phase 4 non-goal: "no general multi-cluster
|
|
# orchestration."
|
|
replicas: 1
|
|
resources: {}
|
|
persistence:
|
|
size: 20Gi
|
|
|
|
api:
|
|
image:
|
|
repository: sentry-api
|
|
tag: latest
|
|
replicas: 2
|
|
resources: {}
|
|
|
|
alerting:
|
|
image:
|
|
repository: sentry-alerting
|
|
tag: latest
|
|
# Pinned to 1 for the same reason as search: rulestore.ClaimDueRules
|
|
# has no leader-election/partitioning story for multiple evaluator
|
|
# replicas yet -- two would both try to claim and evaluate the same
|
|
# due rules. Named explicitly rather than silently defaulted, since
|
|
# it's the kind of knob someone reasonably expects to just work.
|
|
replicas: 1
|
|
resources: {}
|
|
# See templates/alerting.yaml's comment -- only meaningful when
|
|
# enterprise.enabled is true. Empty by default.
|
|
apiServiceToken: ""
|
|
|
|
web:
|
|
image:
|
|
repository: sentry-web
|
|
tag: latest
|
|
replicas: 2
|
|
resources: {}
|
|
# NOT wired to any Deployment env var -- web is a static SvelteKit
|
|
# build (adapter-static, see web/package.json), and VITE_API_BASE_URL/
|
|
# VITE_ALERTING_API_BASE_URL/VITE_ENTERPRISE_AUTH_BASE_URL are baked in
|
|
# at *image build time* (docker-compose.yml's web.build.args), not
|
|
# read at container runtime. Deploying this chart into a real cluster
|
|
# means rebuilding the web image with these three build args pointed
|
|
# at wherever api/alerting/enterprise-auth are actually reachable from
|
|
# a browser (an Ingress host, a LoadBalancer IP, etc.) -- this section
|
|
# exists to document that requirement, not because the chart can act
|
|
# on it.
|
|
builtWithApiBaseURL: "http://localhost:8080"
|
|
builtWithAlertingApiBaseURL: "http://localhost:8081"
|
|
builtWithEnterpriseAuthBaseURL: "http://localhost:8082"
|
|
|
|
# enterprise-auth (commercial license) + the tenant-operator that
|
|
# reconciles the Tenant CRD -- both off by default, matching
|
|
# docker-compose.yml's own "included, not wired into enforcement by
|
|
# default" stance (see its enterprise-auth service comment) and
|
|
# enterprise/README.md's "Status" section on what's built vs. deferred.
|
|
enterprise:
|
|
enabled: false
|
|
image:
|
|
repository: sentry-enterprise-auth
|
|
tag: latest
|
|
# enterprise-api (templates/enterprise-api.yaml) -- swaps in for
|
|
# api.yaml's plain api Deployment when enterprise.enabled is true, on
|
|
# the same Service/port every consumer already expects. Built from the
|
|
# repo root (needs api/ and proto/, not just enterprise/), unlike
|
|
# enterprise-auth's image above -- see
|
|
# enterprise/cmd/enterprise-api/Dockerfile.
|
|
apiImage:
|
|
repository: sentry-enterprise-api
|
|
tag: latest
|
|
replicas: 1
|
|
resources: {}
|
|
# Leave empty to auto-generate (>= 32 bytes) and persist across
|
|
# upgrades -- see templates/secrets.yaml.
|
|
sessionSigningKey: ""
|
|
oidc:
|
|
issuerURL: ""
|
|
clientID: ""
|
|
clientSecret: ""
|
|
redirectURL: ""
|
|
saml:
|
|
entityID: ""
|
|
acsURL: ""
|
|
idpMetadataURL: ""
|
|
|
|
# Installs deploy/operator (the Tenant CRD controller) alongside this
|
|
# chart. Only meaningful when enterprise.enabled is also true -- gated
|
|
# on that, not a separate flag, since a Tenant CR with nothing to
|
|
# reflect (see below) has nothing to do. Also turns on enterprise-api's
|
|
# own Tenant-CRD-syncing permissions (a ServiceAccount/Role, and the
|
|
# TENANT_CRD_NAMESPACE env var) -- see templates/enterprise-api.yaml.
|
|
tenantOperator:
|
|
enabled: false
|
|
image:
|
|
repository: sentry-tenant-operator
|
|
tag: latest
|
|
resources: {}
|
|
|
|
# One entry per tenant to provision -- rendered as Tenant CRs
|
|
# (templates/tenants.yaml), a declarative request an admin/GitOps
|
|
# process makes. The operator (tenant-operator, above) only ever
|
|
# *reflects* real state onto these objects (Phase/Conditions, derived
|
|
# from what enterprise-api's `-provision-tenant` has reported) -- it's
|
|
# `-provision-tenant` (run via `kubectl exec` into the enterprise-api
|
|
# Pod), not the operator, that actually calls ClickHouse and writes the
|
|
# credential Secret. See deploy/operator/internal/controller/
|
|
# tenant_controller.go's and enterprise/internal/tenantcrd's doc
|
|
# comments for the full split. Empty by default; a real two-tenant
|
|
# deployment (Phase 4's exit criteria) sets e.g.:
|
|
# tenants:
|
|
# - name: acme
|
|
# displayName: "Acme Corp"
|
|
# - name: globex
|
|
# displayName: "Globex Corporation"
|
|
tenants: []
|