PtahRetire a used approval
An approval describes one plan against one observed state. Applying it moves that state.
What it shows. Why a signature cannot authorize twice, and what the operator does with one that no longer fits.
A replay of a verified run, not a live cluster. 11 checks held while it was recorded. Play types it out in the frame below; the transcript is the same session, already there.
# A plan is waiting for a decision, and it is named by its fingerprint.$ kubectl -n "$NAMESPACE" get ptahschema storefront -o jsonpath='{.status.phase}{"\n"}{.status.plan.fingerprint}{"\n"}'AwaitingApprovalsha256:e0e49e6a7aa846f8a5d5957aca886d4df47e957b821668d1641e9c141643a12d # Approve it, bound to that schema, that plan and that fingerprint.$ kubectl -n "$NAMESPACE" get ptahschema storefront -o json > demo/.lab/schema.jsonkubectl -n "$NAMESPACE" get ptahschemaplan \ "$(jq -r .status.plan.name demo/.lab/schema.json)" -o json > demo/.lab/plan.jsonjq -n --slurpfile schema demo/.lab/schema.json --slurpfile plan demo/.lab/plan.json ' { apiVersion: "operator.ptah.run/v1alpha1", kind: "PtahSchemaApproval", metadata: {name: "storefront-v1"}, spec: { schemaRef: {name: $schema[0].metadata.name, uid: $schema[0].metadata.uid}, planRef: {name: $plan[0].metadata.name, uid: $plan[0].metadata.uid}, planFingerprint: $plan[0].spec.fingerprint } }' | kubectl -n "$NAMESPACE" create -f -ptahschemaapproval.operator.ptah.run/storefront-v1 created # It converges, and the approval records that it was the one dispatched.$ kubectl -n "$NAMESPACE" get ptahschemaapproval storefront-v1 -o json \ | jq -r '.status.conditions[] | "\(.type)\t\(.status)\t\(.reason)"'Accepted False PlanNoLongerCurrentStale True PlanNoLongerCurrentConsumed True DispatchCommitted # And already stale. It described a plan against the database before the apply.$ kubectl -n "$NAMESPACE" get ptahschemaapproval storefront-v1 -o json \ | jq -r '.status.conditions[] | select(.type == "Stale") | .message'The approved plan no longer matches the current database state # So it cannot authorize a second time. Change the desired state and see.$ eval "$(demo/bin/lab credentials)"export PTAH_OCI_USERNAME PTAH_OCI_PASSWORD PTAH_OCI_REGISTRYDIGEST=$(ptah schema push "oci://$PTAH_OCI_REGISTRY/schemas/demo:v2-$$" \ --schema-file demo/schemas/v2.sql --dialect postgres --plain-http \ | sed -n 's/^Digest: //p')kubectl -n "$NAMESPACE" patch ptahschema storefront --type=merge \ -p "{\"spec\":{\"desired\":{\"ociRef\":\"oci://$REGISTRY_IN_CLUSTER/schemas/demo@$DIGEST\"}}}"ptahschema.operator.ptah.run/storefront patched # A new plan, and the operator waits again. Nothing carries over.$ kubectl -n "$NAMESPACE" get ptahschema storefront -o json \ | jq -r '.status.phase, .status.plan.fingerprint'AwaitingApprovalsha256:e1d07a487ad0a0d9ce0db115abfffed361a6e629a7c48195a75b4c374f3a8252 # And the change nobody approved has not run.$ kubectl -n "$NAMESPACE" exec deploy/demo-psql -- psql -c "\d customers" Table "public.customers" Column | Type | Collation | Nullable | Default--------+--------+-----------+----------+--------- id | bigint | | not null | email | text | | not null |Indexes: "customers_pkey" PRIMARY KEY, btree (id)
What was checked
Every step states what has to hold before its output may be published. A condition is read as its type, status and reason on the live object, never as a phrase in a message.
| Step | Claim | Held |
|---|---|---|
| 1 | exits 0, prints "AwaitingApproval", prints "sha256:" | yes |
| 2 | exits 0, prints "created" | yes |
| 3 | ptahschema/storefront: InSync=True (ScopedConverged) | yes |
| 3 | exits 0, prints "Consumed", prints "DispatchCommitted" | yes |
| 3 | ptahschemaapproval/storefront-v1: Consumed=True (DispatchCommitted) | yes |
| 4 | exits 0, prints "no longer matches" | yes |
| 4 | ptahschemaapproval/storefront-v1: Stale=True (PlanNoLongerCurrent) | yes |
| 5 | exits 0, prints "patched" | yes |
| 6 | ptahschema/storefront: ApprovalRequired=True (Waiting) | yes |
| 6 | exits 0, prints "AwaitingApproval" | yes |
| 7 | exits 0, never prints "signed_up_at" | yes |
What it ran against
- Kubernetes1.37.0
- Operator8c7fe187707f
- Ptahv0.6.0
- Executorsha256:91ec0a6fa27f
- Recorded2026-09-17
- Scenarios at8c7fe187707f
What the commands read
A session is repeated, not admired, so every name in it is one your own environment can carry. There is nothing else: no helper of ours stands between a command and the cluster, and the recorder refuses a step that reads a name this list does not hold. The commands arekubectl, ptah and kubectl ptah, each of which you install once; the last one is the operator’s own read-only client.
- KUBECONFIGthe cluster the commands run against
- NAMESPACEthe namespace the schema and its database credentials live in
- OPERATOR_NAMESPACEwhere the chart installed the operator
- CONTROLLERthe controller Deployment’s name, from that release
- REGISTRY_IN_CLUSTERthe registry address a Pod in the cluster resolves
- PTAH_OCI_REGISTRYthe registry address the push goes to
- PTAH_OCI_USERNAMEthe account that push uses
- PTAH_OCI_PASSWORDits password, which no command prints
A session also uses demo/bin/lab in two places, and both are the lab handing over what it generated rather than doing the demonstration’s work:lab credentials prints the three registry values above, and lab manifestfills the published template with values the step states. Rundemo/acceptance/reproduce.sh to watch the same scenario repeated from a directory where neither exists, by an account that may not create a Job.
The scenario is demo/scenarios/stale-approval.yaml, and make demo replays the whole set against a lab of your own. All recorded runs.