jschoubben
a516ee847b
**The adoption.** Software nobody here wrote, taking its credentials the way such software does — from its environment — and needing two containers that reach each other by name. The first module that could not have been declared this morning: it needs the network shape and it needs a sealed value to reach a container's environment. Its password is accepted rather than generated, which is the whole shape of an adoption: a service that already exists keeps the credential it already has. Asserted properly — a wrong password is refused by the same database, so the passing case means something. **The warm scenario.** A mesh kept between runs and returned to, which turned twelve minutes of bootstrap into thirty seconds of restore. Off unless asked for: a run that is meant to mean something raises from nothing. Its guard fired for real during this work, unprompted — a mesh-host commit landed and it refused the stale base, naming both commits, rather than passing tests against yesterday's binary. That is 04-ISSUES/005's rule one level down. Three things the guard learned the hard way and now handles: a snapshot captures disk and not memory, so the host is restarted after a restore and asserted to have come back; the stocked image digests are worked out while raising and a restored instance never raises, so they are kept; and comparing only the repositories this run can see clears the ones it cannot, so both directions are compared. The one real bug behind five failed attempts was in mesh-host and it reported itself precisely: a network shape the language had and no host implemented. Everything else was scaffolding of mine.
46 lines
1.8 KiB
YAML
46 lines
1.8 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
|
|
|
|
place:
|
|
all: [host, runtime]
|