Terdut operator

Aims to expose most config as CRD's, so end users can self-service over gitops.

See DESIGN.md for the full design: CRD catalog and specs, reconciliation semantics, bootstrap/auth, Postgres integration, RBAC, and the relationship to charts/terdut-server. This README stays a short pitch; the open questions it used to carry are now resolved decisions there (§2).

CRD's

terdutServers

Creates a server — Deployment, Service, database wiring, bootstrap, operator credentials, and allowedTeams consent for cross-namespace teams. See DESIGN.md §4.1, §4.6.

terdutTeams

• team name
• oidc groups
• serverRef — explicit reference to its TerdutServer, may be in a different namespace (one team owns the server, others self-service a team against it), gated by that TerdutServer's own allowedTeams field (DESIGN.md §2, §4.1, §4.2, §4.6)

terdutEscalationrules

• rule
• teamRef — explicit reference to its TerdutTeam (DESIGN.md §2, §4.3)

terdutDeadmansswitches

• rule
• teamRef (DESIGN.md §4.4)

terdutAlertSources

• teamRef (DESIGN.md §4.5)
• URL/key are generated by the server at creation and surfaced only via a generated Secret, never set explicitly

Demo

examples/demo wires one of every CRD above together — two teams, each with an escalation rule, a dead man's switch and an alert source — plus a script that fires synthetic Alertmanager webhooks at it, so you can watch real incidents open, escalate and resolve without a real Alertmanager anywhere in the picture.