novox/mesh-controller
3
0
Fork 0
Code Issues Pull Requests 1 Releases Wiki Activity

The two halves of an object-store edge, as a readable pair

Browse Source 
Manifests for a provider and a consumer, so the contract can be read
rather than only exercised through a lab fixture that stages the grants
by hand.

Checked as a pair rather than separately, because two manifests that
only ever parse alone are two manifests nobody has held against each
other. The test asserts the names match, that each side says where it
wants to be told, and that the consumer contributes the key the
provisioner actually reads.

That last one is the trap worth having a test for: a consumer
contributing "name" — which is exactly what a database consumer
contributes — resolves cleanly, deploys, and then fails on the machine
with "asked for a bucket and did not name it". Nothing in that message
points back at the manifest that caused it. Both mistakes were made
while writing these two files.
This commit is contained in:
jschoubben
2026-08-31 17:52:14 +02:00
parent ed9a30f22d
commit 950ebb9e28
4 changed files with 162 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
examples/modules/README.md
+33
View File
@@ -40,3 +40,36 @@ somewhere — and a static manifest cannot know it.
Neither does, because both name things **the mesh itself named**: the private network's interface
is `mesh0` on every machine, and the address a resolver listens on for the machine's own use is
`127.0.0.54` on every machine. A name the mesh chose is a name a manifest can use.
## Asking for a bucket
`object-store.json` provides one, `photos.json` asks for one. Together they are the whole of an
edge, and they are here as a **pair** because that is the only way to see the halves line up:
| the provider says | the consumer says |
|---|---|
| `provides: s3-bucket` | `requires: s3-bucket` |
| `receives` — where to be told who asked | `contributes: {bucket: photos}` — what it wants |
| `grants` — where their credentials land | `secrets` — where to be given its key |
| `serves` — port, scheme, region | `binds` — where to be told all that |
**The mesh adds the half neither can know**: which machine the provider is on, and where it is on
the private network. Neither manifest names an address, and that is what lets the same pair work
on any mesh.
**`s3-bucket` names the protocol, not the product** ([ADR 0027](../../../hq/02-DECISIONS/)). A
consumer's code is written against the S3 API, and swapping one store for another does not break
it — so the coupling is to S3. A database is the other case: an application is written against
PostgreSQL or against SQL Server, so those provisions name the engine.
**What the pair is checked for.** That the names match, that each side says where it wants to be
told, and that the consumer contributes the key the provisioner actually reads — `bucket`, not
`name`. Contributing `name` (which is what a database consumer contributes) resolves perfectly and
then fails on the machine with *asked for a bucket and did not name it*, which is a long way from
the manifest that caused it.
The provisioner that makes the credential true lives in
[`../objectstore-provisioner`](../objectstore-provisioner), and is proven against a real store in
the lab — including the assertion a database does not need, that **a consumer cannot reach another
consumer's bucket**. One store holds every bucket behind one endpoint, so that isolation is a
policy somebody wrote rather than a boundary the product has.