e4a854f6b0
Two runs on one host destroyed each other's containers, producing mid-test "No such container" failures that look like real defects. The automated builder runs a full local CI on the same box every few minutes, so the machine is contended almost always and this has red-ed both a hand run and an automated gate. Two independent causes are fixed here. Container names were hardcoded, and docker names are global rather than scoped by compose project, so two runs collided on the same name; every name now takes an optional suffix that the harness sets from the run id. And the cleanup sweep matched a label shared by every run, so one run's teardown force-removed another's containers; resources now also carry a per-run label and the sweep can be narrowed to it. A third hazard turned up that was not in the original report: the sidecar suite passes explicit compose project names, which override the run-scoped project and put it outside the shared prefix entirely. Its project names, network, and derived container references are now scoped too. Both are default-off. With the suffix unset, names render exactly as they do today and a bare compose invocation is unchanged, which is what keeps the hosted CI and the documentation correct. A cleanup run with no run id still reaps everything, which is what a manual "clear the box" wants. The literal-name sweep was not sufficient: six scripts build container names dynamically from node labels, and two suites create their own containers outside compose. Those are handled at their construction sites. Verified: syntax check on all modified scripts; compose validation on every modified file with the suffix both set and unset; and a synthetic two-run reproduction that shows the old cleanup destroying a bystander run and the new one leaving it alone. Known gap: subnets are still hardcoded, so two concurrent full runs will still collide on address-pool overlap. That fix reaches into topology configs, chaos scenarios, diagrams and production source, so it is left for its own change rather than half-done here.
BoringTun Throughput Baseline
This harness runs two userspace WireGuard peers with Cloudflare BoringTun and
measures single-stream TCP throughput with iperf3. It is intended as a simple
baseline for comparing FIPS tunnel throughput against another userspace tunnel.
docker build -t boringtun-test:latest testing/boringtun
testing/boringtun/scripts/generate-keys.sh
docker compose -f testing/boringtun/docker-compose.yml up -d
testing/boringtun/scripts/bench.sh
docker compose -f testing/boringtun/docker-compose.yml down
The generated WireGuard key material is written under
testing/boringtun/generated/ and is ignored by git.
For FIPS-to-FIPS revision comparisons, use the static topology comparison script:
testing/static/scripts/iperf-compare-refs.sh origin/master HEAD mesh
That script builds each ref into a separate fips-test:* image, runs the
same static iperf3 topology against both images, and prints a bandwidth
summary for each path. Override DURATION, PARALLEL, SETTLE_SECONDS, or
IPERF_TIMEOUT in the environment when needed. Set RUNS=3 or similar to
repeat each ref and print aggregate results.