Niklas Ye
4ab04d29a8
No operator-mode section existed here before -- terdut-server's own README.md documents the feature, but this repo's design doc never mentioned it. Added as §6 point 7, confirmed against source (internal/api/middleware.go's OperatorModeBlock, router.go's opMode wrapper): it blocks human writes to exactly the resources this operator's CRDs manage (team identity, OIDC-group binding, escalation, dead man's switches, integrations), and nothing else -- team membership, invites, and the on-call schedule/rota stay human-editable regardless, confirmed from the router rather than assumed from the README's prose alone.
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 itsTerdutServer, may be in a different namespace (one team owns the server, others self-service a team against it), gated by thatTerdutServer's ownallowedTeamsfield (DESIGN.md §2, §4.1, §4.2, §4.6)
terdutEscalationrules
- rule
teamRef— explicit reference to itsTerdutTeam(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