jschoubben
c86adbe3cc
Found while checking whether the module vocabulary covers real use cases. A node running three modules that all want a database cannot be planned at all: anchor has 3 modules asking for "postgres-database" and they would share one credential: gitea, keycloak, umami The refusal is right about what it says and wrong about what it implies. They would share one credential, and sharing is worse than refusing — but the arrangement being refused is the ordinary one, and the node this mesh exists to take over runs eight modules against one database server. The cause is the key: a credential is keyed by provision, consumer node and provider node, so `consumer` is a machine. The provisioner inherits it and names the role `mesh_<node>`. The refusal is not a check that caught something; it is the only honest thing that function can do with a key that cannot tell two consumers apart. It is the same mistake as 021 with a different face. There the machine was treated as a trust boundary; here it is treated as an identity, as though "who is asking" is answered by naming a host. Two modules on one node are as separate as two on different nodes. Worth stating plainly: without the refusal, gitea's login would have opened keycloak's database, and nothing would have said so — from the provisioner's side it created exactly what it was asked to create. Not a local fix. It crosses the control plane, the grant file naming and every provisioner that names something after a consumer.
04-ISSUES
The front door for "something is wrong" at the level of the mesh's design or governance. Diagnosis happens here, where the whole mesh is in view; the fix lands in the owning code repository.
What belongs here
| Belongs here | Belongs in the knowledge base |
|---|---|
| The design permits a failure to be silent | How to fix one occurrence of it |
| A documented rule is enforced by nothing | A command that works around it |
| A stated invariant is false in practice | A node-specific quirk |
| The owner is unknown and finding it needs the whole mesh in view | Symptom → fix, once the answer is known |
The knowledge base already holds the operational record and is indexed on symptoms. This folder is not a second copy of it. An issue here is a question HQ must answer; an entry there is an incident someone must clear. An issue whose answer is a general lesson belongs in both.
Structure
NNN-short-name/
00-report.md the symptom as observed, with the evidence; status in frontmatter
01-diagnosis.md the investigation trail, dated, including what was ruled out
Frontmatter, on 00-report.md
---
status: open | diagnosing | located | resolved | wontfix
opened: YYYY-MM-DD
located-in: [] # owning repo(s) or module(s), filled by diagnosis
fixed-by: # pull request or commit reference, filled at resolution
amended-design: # design doc path, when the root cause was a design gap
---
Rules
- Anyone may open an issue. No localisation is required to report one.
- The full flow is playbook
00-META/process/03-issues.md. - Closed issues are never deleted — they are the mesh's symptom-to-component memory.
wontfixis legitimate and requires a sentence saying why.