feat: provision per-service databases for FuzeSales, FuzeContact, FuzeService

[izzywdev]

@claude

Provision per-service Postgres databases and roles on the shared FuzeInfra Postgres instance for three new platform services. This must be fully automated — no manual steps.

What needs to be done

For each service (fuzesales, fuzecontact, fuzeservice), create:

1. A Postgres role/user: <svc>_svc with the password below
2. A Postgres database owned by that role: <svc>
3. Grant all privileges on the database to the role

Connection details

• Postgres host: fuzeinfra-postgres.fuzeinfra.svc.cluster.local:5432
• Admin credentials: from the fuzeinfra-postgres-admin secret in the fuzeinfra namespace

Per-service credentials (already sealed into SealedSecrets in each repo)

These passwords are already sealed — you don't need to store them, just use them to provision:

• fuzesales_svc user password: already in SealedSecret/fuzesales-db-credentials in namespace fuzesales
• fuzecontact_svc user password: already in SealedSecret/fuzecontact-db-credentials in namespace fuzecontact
• fuzeservice_svc user password: already in SealedSecret/fuzeservice-db-credentials in namespace fuzeservice

The provisioning Job pattern should match any existing *-db-bootstrap Jobs in FuzeInfra. The Job runs as a Helm pre-install hook that:

1. Reads the admin password from fuzeinfra-postgres-admin secret
2. Creates the DB user + database idempotently (skip if already exists)
3. The jobs deploy into each service's namespace (fuzesales, fuzecontact, fuzeservice) — these namespaces already exist in the cluster

Acceptance criteria

• All three databases exist on the FuzeInfra Postgres instance
• Each service can connect using DATABASE_URL from its SealedSecret
• Provisioning is idempotent (re-running does not fail)
• Implemented as Helm pre-install Jobs or a FuzeInfra bootstrap mechanism (not one-off kubectl commands)

Context

These services are being deployed as hosted micro-frontends inside FuzeFront. Their Helm charts are in:

• github.com/izzywdev/FuzeSales → helm/fuzesales/
• github.com/izzywdev/FuzeContact → helm/fuzecontact/
• github.com/izzywdev/FuzeService → helm/fuzeservice/

The SealedSecrets referencing these databases are already committed to the feature/devops-*-impl branches of each repo.

STATE: { done: [], remaining: ["provision fuzesales DB+role", "provision fuzecontact DB+role", "provision fuzeservice DB+role"], decisions: [] }

@claude please implement this and reply with the PR link when done.

[claude]

Claude finished @izzywdev's task in 13m 58s —— View job • claude/issue-153-20260705-1041 • [Create PR ➔](https://github.com/izzywdev/FuzeInfra/compare/main...claude/issue-153-20260705-1041?quick_pull=1&title=Issue%20%23153%3A%20Changes%20from%20Claude&body=This%20PR%20addresses%20issue%20%23153%0A%0AGenerated%20with%20%5BClaude%20Code%5D(https%3A%2F%2Fclaude.ai%2Fcode)

---

Per-service Postgres provisioning (fuzesales / fuzecontact / fuzeservice)

• Read issue + gather repo context (Helm chart, Postgres, secrets)
• Consult fuzeinfra-expert + delegate to database-engineer (data-tier owner)
• Design cross-namespace-safe provisioning (verified against the live cluster, read-only)
• Implement idempotent DB+role bootstrap Job
• Wire into values overlays behind enabled gates
• Validate (helm lint / helm template / live idempotency test)
• Commit, push, open PR feat(postgres): idempotent per-service DB+role provisioning (fuzesales/fuzecontact/fuzeservice) #154
• ⛔ Cross-repo hand-off issues — could not auto-open (see below)

---

What landed → PR #154

A GitOps-reconciled, idempotent Helm hook Job (helm/fuzeinfra/templates/service-db-provisioning.yaml) that, per enabled entry in .Values.serviceDatabases, ensures on the shared fuzeinfra-postgres:

1. LOGIN role <svc>_svc (created if absent; password re-synced every run to match the service's sealed value),
2. database <svc> owned by that role (\gexec-guarded — CREATE DATABASE can't run in a txn),
3. GRANT ALL PRIVILEGES, REVOKE CONNECT … FROM PUBLIC, and public-schema ownership/grants (PG15).

It waits on pg_isready, runs post-install,post-upgrade + Argo PostSync (never races an unready DB), and is safe to re-run. Verified with helm lint/kubeconform and a live two-run idempotency test (2nd run skipped creates, re-synced password/owner/grants; confirmed fuzesales_svc logs in, CRUDs a table, PUBLIC can't connect).

Design decision — cross-namespace secrets

A pod reads Secrets only from its own namespace, and the role password must equal what each service sealed for its DATABASE_URL. So the Job runs in fuzeinfra (Postgres superuser creds never leave the namespace / never touch git) and reads each per-service password via secretKeyRef. This requires each consumer repo to also seal <svc>-db-credentials for the fuzeinfra namespace (precedent: fuzekeys-db-credentials, fuzesocial-app-db-credentials already there).

⚠️ Why the DBs aren't created yet — hard cross-repo dependency

Read-only kubectl confirmed none of fuzesales-db-credentials / fuzecontact-db-credentials / fuzeservice-db-credentials exist in fuzeinfra yet (the SealedSecrets in each repo are sealed for the service namespace, which FuzeInfra can't read). Also note the admin secret is actually fuzeinfra-secrets, not fuzeinfra-postgres-admin as the issue assumed — handled via configurable defaults.

So all three are enabled: false in values-contabo.yaml — merging PR #154 is non-breaking (renders no Job) and won't degrade the Argo sync. Each flips to true in the same change that lands its secret.

🙋 Action needed from you (I couldn't open the hand-off issues — FuzeSales/FuzeContact/FuzeService aren't visible to this GitHub App token; they 404 while public repos resolve)

For each of the three repos, seal the DB password into the fuzeinfra namespace:

kubectl create secret generic <svc>-db-credentials \
  --namespace fuzeinfra \
  --from-literal=password='<same password as its DATABASE_URL>' \
  --dry-run=client -o yaml \
| kubeseal --controller-namespace kube-system --format yaml \
> sealed/<svc>-db-credentials.fuzeinfra.yaml

Then flip that service to enabled: true in helm/fuzeinfra/values-contabo.yaml (I'm happy to do the flip PR once the secrets are in — just ping me). If a repo uses a different key than password, it's overridable via serviceDatabases[].passwordSecret.key.

---

DONE: FuzeInfra provisioning mechanism implemented, verified, and shipped in PR #154 (merges non-breaking; disabled until secrets land). BLOCKED (downstream): actual role/DB creation waits on FuzeSales/FuzeContact/FuzeService each sealing <svc>-db-credentials into the fuzeinfra namespace — I couldn't auto-file those hand-off issues (repos not accessible to this token); steps above.
· PR #154