ROS 2 / K8S LAB
Definition of done

Release gates: when the lab can say it works

A supported release is allowed only when it passes eight checks. They exist so the lab never claims that ROS 2 messages cross Kubernetes nodes on the strength of a build that merely succeeded. No gate is claimed as passed today.

Proposal · planning targets, not promisesSource: ROADMAP-2026.md, section 5

Why a green Docker build is not enough

The repository does build a ROS 2 Jazzy image in CI, and a talker and listener exchange a message inside that one container. That is useful, and it is also all the build shows. It says nothing about pods, workers or the network between them.

The rule

A lint-only or successful Docker build is not a substitute for end-to-end ROS DDS verification. DDS (Data Distribution Service) is the messaging layer ROS 2 uses to find peers and deliver messages.

Watch a candidate get stopped

A release candidate has one thing going for it: a passing image build. See how far that gets it.

A passing image build meets the gates

Illustration · nothing here is claimed
A release candidate with only a passing image build is stopped at the first gate A candidate labelled Candidate: build passes sits above a stack of eight release gates: versions documented, clean-room install, cross-node delivery, restart and recovery, safe default access, docs match output, benchmarks with limits, and legacy kept apart. An arrow takes the candidate to the first gate, which is marked Stopped here. The other seven gates are dimmed and labelled not claimed. In the last step the cross-node delivery gate is highlighted with the note that it needs real nodes. Candidate: build passes Versions documentedStopped here Clean-room installnot claimed Cross-node deliverynot claimedneeds real nodes Restart and recoverynot claimed Safe default accessnot claimed Docs match outputnot claimed Benchmarks with limitsnot claimed Legacy kept apartnot claimed
Step 1 of 4

The order on screen is for storytelling. The roadmap lists the eight gates as a checklist, and a release needs every one of them.

The eight gates in plain words

This is the same list as the roadmap, in everyday wording. None has a tick, because none is claimed. The last line of each item says what the repository shows today.

  • Versions are written down

    The ROS distro, Ubuntu, Kubernetes, container runtime, CNI and DDS versions are documented, supported, and pinned where practical.

    Closest evidence today: The Jazzy image pins its base image. The Kubernetes, CNI and DDS parts of a supported profile are not chosen yet.

    Not claimed

  • A fresh install works

    A clean-room install, starting from nothing, finishes on host or VM specs that are recorded.

    Closest evidence today: Fresh-install validations are not measured yet.

    Not claimed

  • Talker and listener run on different nodes

    They start without manual steps, run on different Kubernetes nodes, and pass a scripted check that messages were delivered.

    Closest evidence today: Only a talker and listener inside one container are checked today.

    Not claimed

  • The test survives restarts

    The test covers restart and recovery, uses time limits, writes clear logs and exits with truthful codes.

    Closest evidence today: No cluster-level check exists yet, so nothing covers restarts.

    Not claimed

  • Default settings are safe

    The default setup does not expose long-lived cluster-admin credentials or host storage that anyone can write to.

    Closest evidence today: The historical monitoring setup binds cluster-admin and applies chmod 777.

    Not claimed

  • Docs match what was verified

    README commands, release instructions, badges, links and diagrams match outputs that were checked.

    Closest evidence today: Some ROS2 README commands were corrected in issue #24 by static review only; they were not re-run.

    Not claimed

  • Benchmarks show their work

    Every benchmark figure includes the method, the data, the number of repeats and the limitations.

    Closest evidence today: Historical sample data exists. No modern validated benchmark run is claimed.

    Not claimed

  • Legacy steps are labelled

    The old, unsupported ROS Foxy steps are kept separate and clearly marked as historical.

    Closest evidence today: The Foxy Dockerfile now sits under ROS2/legacy/foxy, but the original manifests still use a Foxy image.

    Not claimed

Source of truth: docs/ROADMAP-2026.md ↗, section 5. Back to the roadmap hub.

If a phase runs late

The plan holds a milestone rather than skipping a gate when upstream dependencies or networking validation take longer. Phases are planning targets, not promises.

See where each gate is worked on

The cross-node delivery work starts in phases 1 and 2, with safer defaults in phase 2. The docs and benchmark gates are worked on in phase 3.

Back to the roadmap