022 fixed; 023 filed — a password is not a connection
022 turned out to have a silent half worth recording: the provider refuses loudly and names the modules, which reads as a decision, while the consuming node does not refuse at all. Three modules wanting one database produce one need, so two of them get no credential file and each starts and fails to authenticate with nothing saying why. 023 is what remained after fixing it. A consumer now gets its own password, in whatever shape its configuration wants, and still cannot connect: the user name is invented by the provisioner and recorded nowhere in the mesh, and the host and port sit in a JSON binding that an application reading KEY=value cannot use. The asymmetry is backwards and the coverage document now says so. The secret is the hard case, because the mesh must not be able to read it, and the secret is the part that arrives. The host and port are ordinary facts the mesh holds in the clear, and they are the ones stuck. Keycloak, Gitea, Mailu and MinIO all parse and resolve and none of them can start. This is what stands between the module set and a running one.
This commit is contained in:
@@ -104,6 +104,28 @@ what kind it is. Small, self-contained, and only interesting once something pres
|
||||
Modules published to a registry and consumed as libraries. This is a *build* output the mesh does
|
||||
not deliver to a node, so it may not belong here at all.
|
||||
|
||||
## What checking the coverage found
|
||||
|
||||
Two faults, both surfaced by asking what a *real* node looks like rather than what a test does.
|
||||
Neither is about the vocabulary; both are about the machinery under it.
|
||||
|
||||
**A credential belonged to a machine, not to a module**
|
||||
([`022`](../../04-ISSUES/022-one-credential-per-node-per-provision-not-per-module/00-report.md),
|
||||
fixed). A node running three services against one database could not be planned at all — and on
|
||||
the consumer's side did not refuse, it just gave two of the three no credential. Every scenario
|
||||
written to date had one consumer per node, which is the natural shape of a small test and not the
|
||||
shape of a machine.
|
||||
|
||||
**A consumer still cannot build a connection string**
|
||||
([`023`](../../04-ISSUES/023-a-consumer-cannot-build-a-connection-string/00-report.md), open). It
|
||||
is given its own password in whatever shape its configuration needs, and the host, port and user
|
||||
name are still out of reach: the user name is invented by the provisioner and recorded nowhere,
|
||||
and the bound values sit in a JSON document that an application reading `KEY=value` cannot use.
|
||||
|
||||
The asymmetry is worth stating, because it is backwards. **The secret is the hard case** — the
|
||||
mesh must not be able to read it — and the secret is the part that now arrives. The host and port
|
||||
are ordinary facts held in the clear, and they are the ones stuck.
|
||||
|
||||
## What the survey found that is not about coverage
|
||||
|
||||
**Declaration and reality had drifted in the system being replaced.** Several live provisions are
|
||||
|
||||
Reference in New Issue
Block a user