Two setup faults, each of which looked like the thing being tested failing. The builder module was assigned without its artifact ever being built, so nothing could start — and the build has to happen while the hand-started builder is still alive. Same chicken-and-egg as the registry, resolved the same way: the builder that exists builds the one that replaces it. The firewall test's listeners were squeezed through three levels of shell quoting and never started, so the test failed on its own setup — which reads exactly like the firewall working.
37 lines
1.2 KiB
YAML
37 lines
1.2 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
|
|
# 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
|
|
|
|
place:
|
|
all: [host, runtime]
|