3 Commits

Author	SHA1	Message	Date
Niklas Ye	6a699d4341	Let TerdutServer customize its pod, and never manage its own ingress ... spec.pod (api/v1alpha1/terdutserver_types.go): annotations, nodeSelector, tolerations, affinity, topologySpreadConstraints, resources, pod and container securityContext, serviceAccountName, extraEnv/extraEnvFrom, extraVolumes/extraVolumeMounts, imagePullSecrets, and an optional disruptionBudget. All direct corev1 passthrough -- no wrapper types buy anything for any of these, matching how CloudNativePG and the Zalando postgres-operator both expose the same knobs, and matching this repo's own SweeperSpec precedent ("wrap only when a round-trip through a different type buys something"). affinity is pure user-supplied passthrough, not a toggle-plus-generated-default the way a multi-replica cluster operator's pod anti-affinity usually is: this operator never auto-generates one, since spec.replicas above 1 isn't a supported topology (the sweeper/notifier singleton constraint). Considered and declined for this round: priorityClassName, pod labels beyond annotations, and a HorizontalPodAutoscaler -- the last of those would directly contradict the singleton constraint above. disruptionBudget is the one field here that isn't a plain PodTemplateSpec knob: when set, the controller now reconciles a PodDisruptionBudget selecting the TerdutServer's own pods (new terdutserver_pdb.go); clearing it deletes any it previously created. New RBAC marker on poddisruptionbudgets to match. Driven by a public-release pass: looking past this project's own use case at what a mature, general-purpose operator CRD exposes here (researched against Zalando postgres-operator and CloudNativePG specifically), not just the fields this install happened to need. Separately, and found while answering a question about exposing TerdutServer through Istio instead of Gateway API: spec.networking's own doc comment quietly promised a Gateway API HTTPRoute this operator would build eventually ("a near-term follow-up, not deferred"). That promise is wrong for a public release -- an operator managing someone's ingress mechanism for them is a worse default than not touching it at all, and a surprise HTTPRoute appearing once that follow-up eventually landed would have been exactly backwards for an Istio (or plain-Ingress, or intentionally-unexposed) install. Made the non-goal explicit and permanent instead (DESIGN.md §1), removed the dead `gatewayListener` field it was the only consumer of (zero runtime call sites anywhere -- setting it already had no effect, so this is a schema cleanup, not a behavior change), and corrected ROADMAP.md's framing. hostname/servicePort stay: both are live (TERDUT_PUBLIC_URL, container/Service port), this operator just never acts on hostname for exposure. Added examples/networking (Gateway API HTTPRoute, Istio VirtualService) showing how to expose the plain ClusterIP Service the operator already creates -- outside the operator itself, as illustrations, not as something examples/demo applies automatically. No new terdut-server version requirement: both changes are CRD/controller- only, nothing about the API this operator's bootstrap flow depends on changed.	2026-10-02 18:50:38 +02:00
Niklas Ye	d9315322fc	examples/demo: fix two real bugs this exact demo just hit live ... 1. Renamed every object this demo creates (TerdutServer, Postgres Secret/Deployment/Service) from terdut-demo[-postgres] to terdut-operator-demo[-postgres]. The user applied this kit into the already-live "terdut-demo" namespace -- the real operator exercise from earlier in this repo's own history -- and this demo's own TerdutServer/Postgres objects shared that exact name. The TerdutServer apply was rejected outright (DatabaseSpec's own CEL rule: adding dsn while the live object already had postgresClusterRef violates "exactly one of" and the API server refused it), and the real Postgres Service was never touched (confirmed live: still Zalando's own spilo selector, endpoint still the real StatefulSet pod) -- but the Postgres Secret and Deployment, having no such protection, were created as brand new, extra, crash-looping objects sitting right next to the real ones. Prefixing every name this demo creates means a repeat of this exact mistake no longer collides with anything, documented directly in README.md now. 2. The actual crash itself, independent of (1): capabilities.drop: ["ALL"] (added responding to a PodSecurity "restricted" warning) took CAP_CHOWN/CAP_FOWNER away from the root user postgres:17-alpine's own entrypoint needs to chown/chmod the data directory before it drops privileges itself -- confirmed in a real crashed pod's logs: `chmod: /var/run/postgresql: Operation not permitted`. kubectl apply --dry-run=server, which is as far as this got verified before, only checks admission policy; it was never actually booted. Removed the capability drop and verified for real this time: applied just 00-postgres.yaml alone into a disposable namespace, waited for the pod to go Ready, read its logs ("database system is ready to accept connections"), then deleted that namespace.	2026-10-02 13:25:47 +02:00
Niklas Ye	ca2cd2c645	Add examples/demo: one of every CRD, plus a script to fire alerts at it ... A self-contained demo kit: a TerdutServer against a throwaway, bare Postgres (bring-your-own DSN -- simplest path to stand up from nothing, ROADMAP.md Stage 1's own note), two TerdutTeams, and each team's own TerdutEscalationRule/TerdutDeadmanSwitch/TerdutAlertSource, so every CRD this operator manages is exercised together rather than in isolation the way config/samples' one-of-each already does. fire-alerts.sh sends terdut-server's own amPayload/amAlert shape (read from internal/api/alertmanager.go in that repo, not guessed from its docs) at whichever TerdutAlertSource's generated webhook Secret it reads the key out of -- high-cpu/disk-full/pod-crash scenarios to open and resolve incidents, and a heartbeat scenario matching each team's dead man's switch matcher, so stopping it demonstrates the switch noticing silence on its own. Verified server-side (kubectl apply --dry-run=server -k examples/demo) against this operator's own dev cluster, which already has these CRDs installed: every object validates. The one warning that cluster's "restricted" PodSecurity raises (postgres:17-alpine's entrypoint needs to start as root before it drops privileges itself) is noted inline in 00-postgres.yaml rather than worked around -- not a real production pattern, and this Postgres exists only to be thrown away with the rest of the demo namespace. README.md walks through: applying, watching status, why a few early CrashLoopBackOff restarts on terdut-demo itself are expected (this operator's Deployment template has no wait-for-postgres init container yet, unlike charts/terdut-server's chart as of v0.33.2), reaching the web UI (port-forward -- spec.networking.hostname is accepted but nothing creates an HTTPRoute for it yet), turning on open signup with the operator's own generated admin token since the bootstrap-created account has no password, firing alerts, and tearing down.	2026-10-02 10:03:49 +02:00