pg-hello-py

A tiny FastAPI + psycopg2 app that exists for one reason: to prove, end to end, that c2a daari secrets bind actually wires a Postgres-shaped Secret into a running pod's environment. It's the demo app for coordinator issue #187 (the appendServiceBinding envFrom-patch fix).

What this is

• GET / — friendly HTML landing page, links to /db-check
• GET /db-check — opens a Postgres connection using POSTGRES_HOST / POSTGRES_PORT / POSTGRES_USER / POSTGRES_PASSWORD / POSTGRES_DB from the environment, runs SELECT 1, and returns:
  • success: {"ok": true, "dbTimestamp": "...", "host": "...", "db": "..."}
  • failure: {"ok": false, "error": "..."} with HTTP 500

The app fails fast at startup (SystemExit(1) with a clear stderr message) if any of the four required env vars is missing. That's deliberate — a silently-missing binding is exactly the failure mode this app exists to catch, so we'd rather crash loudly on boot than serve requests against vars that were never set.

Paketo auto-detects the Procfile (web: uvicorn app:app --host 0.0.0.0 --port $PORT) — no server.py/Node concerns, this is a pure Python buildpack app.

Prereqs

• c2a CLI installed and authenticated (c2a login)
• An active project set (c2a project use <name> — check with c2a project show)
• A reachable Postgres instance (any disposable one works — a local docker run postgres, an RDS dev instance, etc.) with credentials you're willing to paste into a Daari Secret

Manual walkthrough

1. Confirm your active project (see the namespace gotcha below):

   c2a project show

2. Create the Daari Secret holding the Postgres credentials:

   c2a daari secrets create pg-hello-creds \
     --from-literal POSTGRES_HOST=<host> \
     --from-literal POSTGRES_PORT=5432 \
     --from-literal POSTGRES_USER=<user> \
     --from-literal POSTGRES_PASSWORD=<password> \
     --from-literal POSTGRES_DB=<db>

   Note the k8sName printed in the output (in parentheses) — that's what daari secrets bind takes as its second argument, not the display name you typed.

3. Deploy the app from this directory's git remote (or any fork/mirror of it):

   c2a app create pg-hello-py -g <git-url-for-this-repo-or-a-fork>

4. Bind the secret to the app:

   c2a daari secrets bind pg-hello-py <k8sName-from-step-2>

   This exercises the fixed appendServiceBinding path: it writes the pg-hello-py-service-binding Secret's C2A_SYSTEM_ENV JSON and additive-patches the ksvc's envFrom to reference it if it isn't already wired in — the part that used to silently no-op for out-of-lifecycle apps (coordinator#187 part A).

   C2A_SYSTEM_ENV is a single JSON blob (the platform's runtime binding contract — variables / secrets / bindings all serialized together). The platform init step unpacks it into plain env vars before app.py starts, so this app never parses C2A_SYSTEM_ENV itself — it just reads POSTGRES_HOST etc. from os.environ as shown above.

5. Wait for the new revision to become Ready, then verify:

   c2a app show pg-hello-py -f url
   curl "$(c2a app show pg-hello-py -f url)/db-check"

   Expect {"ok":true,"dbTimestamp":"...","host":"...","db":"..."}.

Namespace gotcha (coordinator#187 part B)

c2a daari secrets create uses the CLI's active project's namespace with no override flag and no warning. If you're not sure which project is active, secrets can land in the wrong namespace and go undetected until a bind silently fails to find them. Always run c2a project show first.

Automated version

See e2e.sh for a fully scripted version of the walkthrough above (create secret → deploy app → bind → re-bind for idempotency → wait for Ready → curl /db-check → assert ok:true).