Review: Postgres admin_app user + grants on basketball db

review-1097-2026-04-25 Doc

review needs-refinement

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-crud row exists in project-westside-admin user-stories table
  • [x] arch:postgres-grants label — present
  • [ ] arch note MISSING — arch-postgres-grants note does not exist in pal-e-docs. Parent arch-deployment-westside-admin (referenced from project-westside-admin Architecture section) also does not exist as a backing note. [SCOPE] Create arch-deployment-westside-admin (parent) and either arch-postgres-grants as 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/postgresql provider is registered. terraform/providers.tf + terraform/versions.tf declare 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-alpine Deployment + PVC in pal-e-deployments/overlays/basketball-api/prod/postgres.yaml, namespace basketball-api. CNPG-managed-user pattern (used for paledocs in terraform/modules/database/main.tf:69-78) does not apply here.
  • The closest existing precedent is the paledocs pattern: terraform creates a kubernetes_secret_v1 in the consumer namespace (pal-e-app) holding DATABASE_URL referencing 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_app or 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/postgresql not 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 terraform kubernetes_job_v1) — pick one explicitly.
  • [BODY] Clarify the secret-handoff: does pal-e-platform terraform create the kubernetes_secret_v1 "westside-admin-secrets" directly in the westside-admin namespace (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 note arch-deployment-westside-admin (referenced by project-westside-admin but missing). Either include grants there or create separate arch-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.