3 Commits

Include renames

Author	SHA1	Message	Date
jochen	ef3e5ae9b0	Stamp no commit in this repository's own image recipes either (hq issue 363, review of #292) ... The genesis image copies the whole clone with .git, so its controller carried the commit it was built at, as the bundles did.	2026-10-13 06:47:18 +02:00
jschoubben	1f6793cf0c	The example images build from the Go the manifest pins ... Four example Dockerfiles named golang:1.25 while go.mod requires 1.26; the control plane's image takes GO_BASE from the manifest and these did not, so a build that could not fetch a newer toolchain failed at go mod download (found running the lab through the mesh).	2026-10-02 15:52:25 +02:00
jschoubben	ed9a30f22d	A module can be given a bucket: the provisioner that makes a secret true ... Phase 1.1 of the work breakdown. The finding that shaped it came before any code: **the control plane special-cases nothing.** provides, requires, contributes and grants are entirely name-agnostic, so asking for a bucket needed no change to the mesh at all — only a provider that answers. What was missing was the last step, where something on the machine turns a delivered secret into a key that works. Named `s3-bucket` by ADR 0027's test: 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 the protocol rather than the product — which is what the substrate design already said about AMQP, S3 and OCI. Proven on a real store, 7 assertions: a generated secret becomes a working key; rotation makes the new one work and the old one stop; a consumer that goes away loses its key; a key nobody here made is left alone; a manifest naming a credential that was never written is refused; an unusable bucket name is refused naming the consumer that asked. **And the one a database does not need.** One PostgreSQL server holds separate databases and the product enforces the boundary; one object store holds every bucket behind one endpoint, so a consumer being unable to reach another's is a policy somebody wrote. A policy granting arn:aws:s3:::* would pass every other test in the file, so the unit tests assert what the policy does NOT say. It drives the vendor's command line rather than an SDK: the admin API encrypts its request bodies, which is why a separate admin library exists, and pulling that in would add a system-metrics dependency tree to a repository with none in order to create a user.	2026-08-31 17:51:12 +02:00