What stands between 3.1 and a running identity provider is a program

023 is fixed, so the design faults are gone and one concrete thing is
left: the realm provisioner does not exist. Its manifest named an image
nothing builds and no program backs, which has been removed — a manifest
describing a program nobody wrote is the same mistake as the credential
files that could never be read.

Keycloak's manifest now says what is true today, and the gap is loud: it
no longer claims to provide oidc-client, so a consumer asking for one is
refused by name at plan time instead of resolving cleanly and waiting
for a client nothing will create.

The provisioner should be written against a real Keycloak in the lab
rather than from the API documentation. The object store's took three
corrections that only a running server produced.
This commit is contained in:
2026-09-01 03:13:11 +02:00
parent 0760280bc6
commit 39916b26e9
+21 -1
View File
@@ -281,7 +281,27 @@ path named `.env` and read it as one, when a sealed file holds a password and no
parsed and resolved and could never have worked, which is what a manifest checked only by a parser
buys. Two tests now refuse both halves of it.
**023 is the whole of what remains before 3.1 runs.**
### 3.1 needs a program, not a decision — *2026-09-01*
023 is fixed, and with it the two design faults are gone. What stands between 3.1 and a running
identity provider is now one concrete thing: **the realm provisioner does not exist.**
Its manifest named an image — `mesh-provision-keycloak` — that nothing builds and no program
backs. That has been removed rather than left standing, because a manifest describing a program
nobody wrote is the same mistake as the credential files that could never be read: it parses, it
resolves, and it could never work.
So Keycloak's manifest now says what is true today — a server the mesh runs, with its database
and its admin credential, both reaching it in a shape it can read. It no longer claims to provide
`oidc-client`, which means a consumer asking for one is **refused by name at plan time** rather
than resolving cleanly and waiting for a client nothing will create.
The provisioner is the same shape as the two that exist: it reads what the mesh granted and
reconciles a realm and a client per consumer. **It should be written against a real Keycloak in
the lab**, not from the API documentation — the object store's took three corrections that only a
running server produced.
The forge (3.2) and the mail system (3.3) need no provisioner and are not blocked on this.
## The conversion is done by hand, and that is a decision