jschoubben
44d3e53bcb
**A password beginning with a dash broke the search for it.** The credential test greps the machine's own files for the delivered password; this run's password started `-S`, so grep read it as an option and refused the whole invocation. The test compared the usage message against "0" and reported the password as leaked. That is the worst way for a search to fail — it says it found something. Fixed with `-e` and `--`, which is what those exist for. **The planning test could not redirect what the scenario does not serve.** Rewriting an image reference only works for repositories the scenario's registry actually holds, and the object store's provisioner was not stocked — so that module kept its placeholder and the refusal fired, correctly. It is stocked now, so all five are planned again. The skip path stays for anything genuinely unserved, and says which module and why: a planning test quietly covering four instead of five is the false coverage this suite exists to prevent. **The forge failed because of the one above it.** The planning test threw before its cleanup could run, leaving a module assigned that refused the next push, so no database container was ever created. Yesterday's fix moved that cleanup where a failure cannot skip it — but `after` still only unassigns what was assigned, so it now tracks what actually got added rather than what was intended.
53 lines
2.3 KiB
YAML
53 lines
2.3 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
|
|
laptop:
|
|
at: { segment: hosting, address: [192.0.2.20] }
|
|
inbound: allow
|
|
|
|
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 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]
|