jschoubben
2f2f1d931e
A consumer contributes a key prefix and gets an ACL user; the test is that the grant means exactly what the manifest said, in both directions: its own keys usable, anyone else's refused by the store itself, and the flush a tenant must never have refused with them. Waited for through the store rather than through logs: the user list, asked with the password the host wrote into the server's own conf file on the machine — nothing invented, both ends reading what the mesh delivered. And the forge is asked on the port the mesh assigned, not the one the module declared. The old curl aimed at 3000, which was right until ADR 0038 moved the machine side — a latent break that would have fired on the first run to get past the settling that used to fail first. The scenario stocks redis and its provisioner, and the rebuild builds the provisioner image with the others.
64 lines
3.0 KiB
YAML
64 lines
3.0 KiB
YAML
# Two machines, one mesh.
|
|
#
|
|
# The first raises everything from the bundle its host carries and joins the mesh it made. The
|
|
# second is an ordinary node: it has a host and nothing else, and a person carries it a token.
|
|
#
|
|
# This is the first scenario where the mesh is a mesh. Everything before it proved a machine could
|
|
# talk to a control plane on its own loopback, which proves less than it looks.
|
|
scenario: two-nodes
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
inbound: allow
|
|
# The whole substrate, the registry, the builder, an adopted workload and the modules under
|
|
# test all land here — eleven containers before the forge arrives. At the 1GiB default this
|
|
# machine thrashes, and it presents as "the mesh hangs": every exec slows from 15s to 105s
|
|
# and the forge test fails on a status poll that is merely queued behind page-outs.
|
|
memory: 4GiB
|
|
cpus: 4
|
|
laptop:
|
|
at: { segment: hosting, address: [192.0.2.20] }
|
|
inbound: allow
|
|
memory: 2GiB
|
|
|
|
images:
|
|
- postgres:17-alpine
|
|
- cloudamqp/lavinmq:latest
|
|
- mesh-control:development
|
|
# So a module can mirror one into a registry of the mesh's own. The scenario's registry serves
|
|
# what the mesh's registry is built from — the same chicken-and-egg the bootstrap has, resolved
|
|
# the same way.
|
|
- registry:2
|
|
# A real third-party workload, for adopting one the way the conversion will. Its database is
|
|
# the substrate's postgres image rather than its own: what is under test is the mesh delivering
|
|
# a module, not which postgres it delivers.
|
|
- ghcr.io/umami-software/umami:postgresql-latest
|
|
# And the builder, because it is a module the mesh assigns rather than a program somebody
|
|
# starts by hand — which is the only way its credential can be one the mesh delivered.
|
|
- mesh-builder:development
|
|
# And the provisioner, which is what makes a sealed credential true on a machine — the mesh
|
|
# discarded the plaintext and cannot tell a database to start accepting it.
|
|
- mesh-provision-postgres:development
|
|
# And the proxy, which is what turns a route grant into traffic actually arriving.
|
|
- mesh-route-proxy:development
|
|
# And the cache, with its provisioner — the third provision after a database and a bucket,
|
|
# and the first whose tenancy is a keyspace rather than a namespace something else enforces.
|
|
- redis:7-alpine
|
|
- mesh-provision-redis:development
|
|
# And the object store's provisioner, so the module describing it can be planned. Without it
|
|
# that module still names an image nothing serves, and planning it is refused — correctly.
|
|
- mesh-provision-objectstore:development
|
|
# And a forge, so one of the real module descriptions can be started rather than only planned.
|
|
# It is the first of them to run: it needs a database from another module, a credential it did
|
|
# not choose, and a connection string it could not have written itself.
|
|
- gitea/gitea:1.22
|
|
|
|
place:
|
|
all: [host, runtime]
|