From 62ff9a5bd31de6c3dd4660a6459e24e0cd81c1d7 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 21 Sep 2026 17:50:42 +0200 Subject: [PATCH] Issues 046, 049 and 069 located, each with the decision its fix needs named --- .../00-report.md | 4 ++-- .../01-diagnosis.md | 17 +++++++++++++++ .../00-report.md | 4 ++-- .../01-diagnosis.md | 18 ++++++++++++++++ .../00-report.md | 4 ++-- .../01-diagnosis.md | 21 +++++++++++++++++++ 6 files changed, 62 insertions(+), 6 deletions(-) create mode 100644 04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/01-diagnosis.md create mode 100644 04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/01-diagnosis.md create mode 100644 04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md diff --git a/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md b/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md index 74ee275..b1ed533 100644 --- a/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md +++ b/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md @@ -1,7 +1,7 @@ --- -status: open +status: located opened: 2026-09-14 -located-in: [] +located-in: [mesh-controller internal/builder (upstream artifacts)] fixed-by: amended-design: --- diff --git a/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/01-diagnosis.md b/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/01-diagnosis.md new file mode 100644 index 0000000..0d4fdfd --- /dev/null +++ b/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/01-diagnosis.md @@ -0,0 +1,17 @@ +# Diagnosis — 2026-09-21 + +1. What was established stands: the failure is in going through a machine's image store, whose + newer store keeps an index and refuses to push a single platform out of it. Every variant of + pull-then-push was tried and failed the same way. +2. The first open question answers the other two. A copy between registries never needs a + platform, because it moves what is there — the index and every manifest it names, or one + manifest if the module says so. The registry API is enough for it: read the index, read each + manifest, mount or upload each blob by digest, put the manifests and then the index under the + module's repository. No image store is involved and the runtime's behaviour stops mattering. +3. Whether the mesh mirrors an index or a platform is then a choice the copy can offer rather + than a limitation; today every machine on one mesh is the same architecture, and that + assumption is now written down here rather than nowhere. + +**Located in:** the builder's upstream-artifact step. Not fixed here: a registry-to-registry copy +is a few hundred lines against the registry API and is proven only against a real registry +serving a real index, which is a lab run of its own. diff --git a/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/00-report.md b/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/00-report.md index 7bab926..aa0a36d 100644 --- a/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/00-report.md +++ b/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/00-report.md @@ -1,7 +1,7 @@ --- -status: open +status: located opened: 2026-09-14 -located-in: [] +located-in: [mesh-controller cmd/mesh-controller, mesh-tools (the request contract)] fixed-by: amended-design: --- diff --git a/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/01-diagnosis.md b/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/01-diagnosis.md new file mode 100644 index 0000000..ab791e9 --- /dev/null +++ b/04-ISSUES/049-a-module-can-serve-tools-and-nothing-can-call-them/01-diagnosis.md @@ -0,0 +1,18 @@ +# Diagnosis — 2026-09-21 + +1. The refusal is the scope working as designed: a module's broker account covers what it emits + and consumes and nothing else. A tool call needs a reply queue the caller creates and a publish + to the serving module's request queue, and no declared scope grants either. +2. Of the three callers the report names, two already have an account with the right shape. The + controller holds an admin connection to the broker, and an agent acting for an operator runs + through the controller. Another module is the only caller that would need something minted. +3. The honest first step is therefore the third option in the report: the controller is the way + in. A `mesh-controller ask ` needs no new account, routes every question + through one process — which is where an audit of who asked what belongs anyway — and settles + what a module declares about being asked by declaring nothing: serving a tool is being + askable through the controller. A module-to-module call, if one is ever wanted, is a grant + like any other, and a later decision. + +**Located in:** the controller (a command speaking the tool request/reply over its own connection) +and the tool runtime's request contract. Not fixed here: it is a new command against a protocol +the runtime owns, and needs a lab run against a tools-only bed to be proven. diff --git a/04-ISSUES/069-one-secret-provision-yields-one-value/00-report.md b/04-ISSUES/069-one-secret-provision-yields-one-value/00-report.md index 047d445..4ab4d54 100644 --- a/04-ISSUES/069-one-secret-provision-yields-one-value/00-report.md +++ b/04-ISSUES/069-one-secret-provision-yields-one-value/00-report.md @@ -1,7 +1,7 @@ --- -status: open +status: located opened: 2026-09-20 -located-in: [] +located-in: [mesh-controller internal/catalogue (requires/secrets), mesh-controller internal/inventory (secret key)] fixed-by: amended-design: --- diff --git a/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md b/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md new file mode 100644 index 0000000..b6511d7 --- /dev/null +++ b/04-ISSUES/069-one-secret-provision-yields-one-value/01-diagnosis.md @@ -0,0 +1,21 @@ +# Diagnosis — 2026-09-21 + +1. The constraint is real and where the report put it: a module requires a provision name once, + a pair credential is keyed on (name, consumer node, consumer module, provider), and the login + the vault derives is keyed on the (node, module) pair. Two secrets for one module and one vault + collide on every key. +2. The third question was answered by reading the ten modules. Six of the "two" cases hold two + names for one value or a value derived from another (an admin password and a token only ever + set from it, a relay user that is a fixed string beside the relay password). Those are one + secret each, and the module's own business to derive from. The "three or more" cases are + genuinely independent: a root certificate, its key and that key's password are three values + with three lifetimes. +3. So the answer is neither option as the report framed them. A module keeps one `secret` + provision per independent value, and needs a way to require the same provision name more than + once under distinct local names — the way `secrets:` already maps a provision to a path. That + is a manifest-vocabulary decision, and it moves the pair key: the credential must be keyed on + the local name, not the provision name, or the second pair overwrites the first. + +**Located in:** the manifest's `requires`/`secrets` vocabulary (the catalogue parser) and the pair +credential's key (the controller's secret store). Not fixed here: the key change touches every +existing pair and belongs in a feature of its own, with a lab run against the vault bed.