# Two machines: one is the substrate, the other carries a lavinmq PROVIDER and a consumer of it.
#
# lavinmq is the mesh's own control-plane broker (mesh-broker), and it is ALSO offered as a
# user-facing capability: a module that needs a message queue gets its OWN broker — a scoped vhost and
# user on a lavinmq PROVIDER — not an account on the control broker. That makes lavinmq the sharp
# two-node case, for the same reason two-node-db is: the substrate's broker publishes 5672 on the node
# it runs on, and a lavinmq provider must publish 5672 too for its consumers to reach it — so the two
# cannot share a machine. The moment a real amqp provider must own a node's 5672, it collides with the
# control broker already there, and the chain is blocked single-node.
#
# This is the split that unblocks it. `anchor` runs the substrate (store, broker, control) and NOTHING
# else. `laptop` runs the whole chain: the lavinmq PROVIDER and the amqp-ping CONSUMER that requires
# it. Provider and consumer are co-located on laptop, so the grant never crosses a node boundary; only
# enrolment crosses to anchor, over the underlay both machines share. And because the substrate broker
# is on the OTHER node, the provider owns laptop's 5672 uncontested.
#
# It needs a host binary and the substrate bundle:
#
#   MESH_LAB_HOST_BINARY=.../mesh-host   MESH_LAB_BUNDLE=.../examples/substrate-first-node.lock
#
# HELPER — stock the two runtimes into the local daemon before the run (some may already be there):
#   scripts/build-module-runtime.sh lavinmq   /tmp/lavinmq.tar
#   scripts/build-module-runtime.sh amqp-ping /tmp/amqp-ping.tar
# The service image cloudamqp/lavinmq:latest must be in the local daemon too — it is already stocked as
# the substrate's own broker image; each node pulls what it runs from the scenario's own registry by
# digest.
scenario: lavinmq-bed

segments:
  hosting:
    kind: public
    cidr: [192.0.2.0/24]

machines:
  anchor:
    at: { segment: hosting, address: [192.0.2.10] }
    inbound: allow
    memory: 3GiB
    cpus: 2
  laptop:
    at: { segment: hosting, address: [192.0.2.11] }
    inbound: allow
    memory: 3GiB
    cpus: 2

images:
  # The first-node substrate: store, broker (itself lavinmq), control.
  - postgres:17-alpine
  - cloudamqp/lavinmq:latest
  - mesh-control:development
  # The lavinmq provider's runtime (reused for its run-once bootstrap and its provisioner) and the
  # amqp-ping consumer's runtime, both built by scripts/build-module-runtime.sh into the local daemon
  # and stocked into the scenario's own registry, which is where the hosts pull them from by digest.
  # The lavinmq SERVICE image is cloudamqp/lavinmq:latest, already stocked above.
  - mesh-runtime-lavinmq:development
  - mesh-runtime-amqp-ping:development

place:
  all: [host, runtime]