A bucket is the one the mesh derives, and the photos module named another #96

2026-09-26T14:46:25Z

jschoubben commented

2026-09-26 14:46:25 +00:00

Found while answering "where should the bucket name come from?" — the answer is that it comes from the login, and no manifest decides it.

The minio provisioner does bucketFor(p.as): it derives the bucket from the access-key identity the mesh minted, creates that one, checks that one, removes that one. Its own comment says why — "The bucket is derived from the login, so teardown recomputes it with nothing to persist." The bucket a consumer contributed is read by nothing.

Three modules contributed one anyway. Decorative in two, and wrong in the third:

photos told its container MINIO_BUCKET=photos — the predecessor's bucket — while the key the mesh scopes for it is confined to mesh-novox-photos. Deployed as it stood it would have authenticated successfully and then been denied on every object, which reads like a credential fault and is not one.
nextcloud and invoicing had hand-copied the derived name correctly, so they worked by transcription.

This PR: photos names the bucket the mesh actually provisions, and the contributed bucket key is gone from all three. Each still lists s3-bucket under requires, which is what makes the mesh mint the grant — a require-only consumer asks for a provision whether or not it hands anything up with it. Removed entirely rather than left empty, since an empty contribution is refused by the manifest check.

Verified against the live store before changing anything, because a wrong answer here moves 174.9 GiB: the derived names are the populated buckets — mesh-novox-ncloud (77,886 objects, 174.9 GiB), mesh-novox-photos (155 objects, matching the predecessor's photos exactly), mesh-novox-invoice (414 objects, matching invoicing). Nothing has to move, and nextcloud's env keeps pointing where its data already is.

Manifests parse through the controller's own ParseManifest; go test ./... in mesh-controller: 19 packages, exit 0.

What is not fixed here is why the value had to be transcribed at all: nextcloud and photos still state the bucket in an env line, because a consumer has no way to be told a value its provider derived per consumer. Filed separately.

Found while answering "where should the bucket name come from?" — the answer is that it comes from the login, and no manifest decides it. The minio provisioner does `bucketFor(p.as)`: it derives the bucket from the access-key identity the mesh minted, creates that one, checks that one, removes that one. Its own comment says why — *"The bucket is derived from the login, so teardown recomputes it with nothing to persist."* **The `bucket` a consumer contributed is read by nothing.** Three modules contributed one anyway. Decorative in two, and wrong in the third: - `photos` told its container `MINIO_BUCKET=photos` — the predecessor's bucket — while the key the mesh scopes for it is confined to `mesh-novox-photos`. Deployed as it stood it would have authenticated successfully and then been denied on every object, which reads like a credential fault and is not one. - `nextcloud` and `invoicing` had hand-copied the derived name correctly, so they worked by transcription. This PR: `photos` names the bucket the mesh actually provisions, and the contributed `bucket` key is gone from all three. Each still lists `s3-bucket` under `requires`, which is what makes the mesh mint the grant — a require-only consumer asks for a provision whether or not it hands anything up with it. Removed entirely rather than left empty, since an empty contribution is refused by the manifest check. **Verified against the live store before changing anything**, because a wrong answer here moves 174.9 GiB: the derived names are the populated buckets — `mesh-novox-ncloud` (77,886 objects, 174.9 GiB), `mesh-novox-photos` (155 objects, matching the predecessor's `photos` exactly), `mesh-novox-invoice` (414 objects, matching `invoicing`). Nothing has to move, and nextcloud's env keeps pointing where its data already is. Manifests parse through the controller's own `ParseManifest`; `go test ./...` in mesh-controller: 19 packages, exit 0. What is **not** fixed here is why the value had to be transcribed at all: `nextcloud` and `photos` still state the bucket in an env line, because a consumer has no way to be told a value its provider derived per consumer. Filed separately.

jschoubben added 1 commit 2026-09-26 14:46:25 +00:00

A bucket is the one the mesh derives, and the photos module named another ddb67fc095

The provisioner derives a consumer's bucket from the login the mesh minted — 'derived from the
login, so teardown recomputes it with nothing to persist' — and never reads the bucket a manifest
contributed. Three modules contributed one anyway, and the value was decorative in two and wrong in
the third: photos told its container MINIO_BUCKET=photos, the predecessor's bucket, while its minted
key is scoped to mesh-novox-photos. Deployed as it stood, it would have authenticated and then been
denied on every object.

photos now names the bucket the mesh actually provisions, and the contributed bucket is gone from
all three: a value nothing reads, that reads as though it decides.

Verified against the live store before changing anything: the derived names are the populated ones —
mesh-novox-ncloud (77,886 objects, 174.9 GiB), mesh-novox-photos and mesh-novox-invoice. Nothing has
to move.

jschoubben merged commit 382a44621e into main

2026-09-26 14:46:30 +00:00

jschoubben deleted branch fix/a-bucket-is-the-one-the-mesh-derives

2026-09-26 14:46:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#96