Define the reference path
Before anything is built, the lab needs one clear target: which versions it supports first, and what a passing test across two workers looks like. This phase picks that target and designs the test. It does not claim the test passes.
Why this phase comes first
A ROS 2 message has to leave one pod, cross the cluster network and arrive in another pod. Today only a much smaller step is checked: a talker and a listener exchanging a message inside one container.
Inside one container
The Jazzy image builds in CI and passes a local talker and listener check. This is the only hop the repository checks today.
Between two workers
No test shows a message crossing from one Kubernetes worker to another. That is what the reference path is designed to prove later.
The original cluster
The Vagrant lab uses ROS 2 Foxy (end of life), Kubernetes 1.29 and Weave Net. It stays as a historical example.
One message, three hops
A message makes three hops: out of the talker pod, across the cluster network (the CNI), and into the listener pod. Press play to see how the four tasks of this phase build up that picture. The dashed path is a plan, not something that has run.
A planned path between two workers
Illustration · conceptual pathThe hollow marker is a conceptual message, not a measurement. The only hop the repository checks today is the one inside a single container.
What done looks like
This phase ends when the team agrees what a passing smoke test (a short check that the basics work) must show. These are draft exit conditions, taken from the release gates. The phase defines them, it does not meet them.
Draft exit conditions for the smoke test
- The talker and listener start on their own, with no manual
kubectl execinto a pod. - They run on different Kubernetes nodes.
- A script checks that messages arrive, stops after a time limit, and exits with a truthful pass or fail code.
- Every result, including failures, is written into the compatibility matrix with the versions used: ROS distro, Ubuntu, Kubernetes, container runtime, CNI and DDS.
What this phase will not claim
DDS (Data Distribution Service) is the messaging layer ROS 2 uses. The plan states that feature or performance claims must not rest on static YAML alone, and that a Docker build or lint pass does not replace an end-to-end ROS check.
Issues in this phase
Status labels come from what the repository's files show, not from the state of the issue on GitHub.
- #7Container tested
Modern ROS 2 baseline
Pinned Jazzy image and verified sample nodes, with legacy Foxy marked end of life. The image exists; the Kubernetes side of the profile is not chosen yet. Issue #7 ↗
- #14Not yet verified
Talker and listener across workers
A repeatable command shows messages crossing nodes without
kubectl exec, and ROS workloads are separated from stress workloads. Issue #14 ↗ - #15Planned
Maintained CNI and explicit discovery
Replace the archived Weave Net with a maintained plugin and set DDS discovery on purpose, then test discovery, restart and debugging across workers. Issue #15 ↗
Source of truth: docs/ROADMAP-2026.md ↗, section 4. Back to the roadmap hub.