Review: Postgres admin_app user + grants on basketball db
Verdict: NEEDS_REFINEMENT
Board item #1097 — Forgejo
forgejo_admin/pal-e-platform#302. Type: Task. Reviewed against template-issue (Task variant uses Scope, not File Targets).Template Completeness
- [x] Type — "Task"
- [x] Lineage — companion to westside-admin deploy, can start independently
- [x] Repo —
forgejo_admin/pal-e-platform - [x] User Story —
story-westside-admin-admin-row-crud - [x] Context
- [x] Scope
- [x] Acceptance Criteria — 8 testable items
- [x] Test Expectations
- [x] Constraints
- [x] Checklist
- [x] Related
Traceability
- [x] story:admin-row-crud label — present
- [x] story note verified —
story-westside-admin-admin-row-crudrow exists inproject-westside-adminuser-stories table - [x] arch:postgres-grants label — present
- [ ] arch note MISSING —
arch-postgres-grantsnote does not exist in pal-e-docs. Parentarch-deployment-westside-admin(referenced from project-westside-admin Architecture section) also does not exist as a backing note. [SCOPE] Createarch-deployment-westside-admin(parent) and eitherarch-postgres-grantsas a sub-note or roll grants into the parent. - [x] Forgejo issue — open, valid (#302)
Repo Placement
OK — pal-e-platform owns all IaC + Postgres provisioning. Companion kustomize wiring lives in pal-e-deployments (already covered by separate board item #1095, issue pal-e-deployments#133).
Scope vs. Reality (file/code investigation)
The issue body presents 3 provisioning options and tells the agent to "inspect
~/pal-e-platform/ to identify how Postgres users are currently managed." Pre-review findings:- No
cyrilgdn/postgresqlprovider is registered.terraform/providers.tf+terraform/versions.tfdeclare hashicorp/kubernetes, hashicorp/helm, aminueza/minio. Option 1 is therefore add provider + create role, not "follow existing pattern." - basketball-api Postgres is NOT a CNPG cluster. It is a plain
postgres:16-alpineDeployment+ PVC inpal-e-deployments/overlays/basketball-api/prod/postgres.yaml, namespacebasketball-api. CNPG-managed-user pattern (used for paledocs interraform/modules/database/main.tf:69-78) does not apply here. - The closest existing precedent is the paledocs pattern: terraform creates a
kubernetes_secret_v1in the consumer namespace (pal-e-app) holdingDATABASE_URLreferencing the CNPG cluster. For basketball, there is no equivalent CNPG-managed-user mechanism — the role must be created via SQL against the running Deployment. - No existing
admin_appor sub-user pattern exists anywhere in pal-e-platform or pal-e-deployments.
Dependencies
Foundational — blocks pal-e-deployments#133 (kustomize secret consumer, board item #1095) and the SvelteKit DB-connection work in westside-admin#6, #7. Currently 11 items on board-westside-admin in backlog; this is a top-of-pipeline item. No blockers above it.
Acceptance Criteria
All 8 AC are testable and verifiable by an agent (psql commands explicit, secret reference documentable). The blocked AC (CREATE TABLE → permission denied) is the strongest signal that grants are correct. AC are good.
Blast Radius
Low if executed correctly. Same plain-Postgres Deployment pattern is used by other westside services (westsidekingsandqueens, westside-streamlit) — the same admin_app pattern would extend cleanly if needed later, but only basketball is in scope here. Do not reuse
basketball-api-secrets for the new credential — keep it in a fresh Secret to keep blast radius isolated.Decomposition Assessment
~3-4 files (terraform addition + secret + SOP if needed), 8 AC but all run in ~1 minute of psql. Estimated agent work: 5-10 min depending on path chosen. Fits a single agent pass. No decomposition needed.
Recommendation
[BODY]Replace "Inspect ~/pal-e-platform/ to identify how Postgres users are currently managed" + 3-option fork with a concrete chosen approach. Pre-investigation already done in this review:cyrilgdn/postgresqlnot registered, basketball is not CNPG. Recommended approach: a one-shot Job/migration applied via the basketball-api kustomize overlay (Option 2), OR add a small SQL bootstrap (psql exec via terraformkubernetes_job_v1) — pick one explicitly.[BODY]Clarify the secret-handoff: does pal-e-platform terraform create thekubernetes_secret_v1"westside-admin-secrets" directly in thewestside-adminnamespace (paledocs precedent), or does the kustomize overlay in pal-e-deployments#133 create it from a SealedSecret/sops file? Pick one and document the contract so issue #1095 has an unambiguous consumer side.[BODY]Remove or downgrade the "Terraform via cyrilgdn/postgresql" option — it would require also adding the provider + reaching into the basketball-api namespace's running Deployment, which is more scope than the ticket implies.[SCOPE]Create architecture notearch-deployment-westside-admin(referenced by project-westside-admin but missing). Either include grants there or create separatearch-postgres-grants. Foundational refinement; should not block ticket execution but story:arch traceability is incomplete without it.
Once body is tightened (concrete approach + secret handoff contract) and arch note is sketched (even a stub), this ticket is READY.