[TheSentinel454]

Summary

buzz-loadgen (#8636) has no container image, so you can't run it as a Kubernetes Job. The relay Dockerfile builds only buzz-relay, buzz-admin, and buzz-pair-relay.

This PR adds:

• Dockerfile.loadgen. It builds a static musl buzz-loadgen on the same pinned rust:1.98-alpine3.22 base that Dockerfile.sprig uses, then copies it into pinned alpine:3.22 with ca-certificates. Each native-arch build runs buzz-loadgen --help after strip. The image runs as numeric UID/GID 10001 so runAsNonRoot can verify it, and buzz-loadgen is the entrypoint.
• .github/workflows/loadgen-image.yml, modeled on sprig-image.yml. It builds natively on amd64 and arm64, pushes by digest, merges a multi-arch manifest, and attests provenance.
  • Pushes to main that touch buzz-test-client, buzz-ws-client, buzz-core, or the workspace manifests publish :main and :sha-<7>.
  • PRs that touch the Dockerfile or workflow build without pushing an image. Same-repo PRs still write the registry build cache (buzz-loadgen-buildcache), as sprig-image.yml does.
  • Crate changes are only built on main, so a change that breaks the musl build first fails on the main push. Sprig makes the same tradeoff.
  • You can also publish manually with workflow_dispatch.
• A short paragraph in perf/LOADGEN.md covering the image and how to pass shard arguments.

Why it's not in the relay image: that would ship a load tool in every production relay image. It would also make commits that only touch the test client count as relay-image changes.

Rollout

Merging triggers the first publish.

1. GHCR creates the package as private. An org admin makes ghcr.io/block/buzz-loadgen public once, the same as buzz-sprig.
2. Check the first publish:
   • docker buildx imagetools inspect ghcr.io/block/buzz-loadgen:main lists amd64 and arm64.
   • gh attestation verify oci://ghcr.io/block/buzz-loadgen:main --owner block passes.
   • An anonymous docker pull works once the package is public.
3. Rollback: revert the workflow. Nothing consumes the image yet.
4. The PR author watches the first main run and the first Job that uses the image.

Simpler or more complex: this adds two files and no Rust changes. The workflow has fewer moving parts than sprig-image.yml: no semver tags, no :latest, and no image-name override variable.

Related issue

None found. Follows #8636.

Testing

• PR CI built both architectures natively.
• An arm64 local docker build at 2c18186a:
  • --help exits 0. The image config is User=10001:10001, and the container runs as uid 10001.
  • A missing scenario exits 1, --shard 5/2 exits 2, and malformed TOML exits 1 with the parse error.
  • seed against an address with no listener exits 1 with "Connection refused".
  • The system store loads its CA roots: https://example.com completes the handshake, and a self-signed host is rejected with UnknownIssuer.
• The build-stage --help check runs on both architectures in CI from c24ee76b on.
• Not yet exercised: kubelet runAsNonRoot admission. The first Indexed Job is that check.

🤖 Generated with Claude Code

[github-actions]

🔐 Codex Security Review

Note: This is an automated, security-focused review generated by Codex.
Use it as a supplement to human review; false positives are possible.

Scope

• Exact PR diff: ef4130da4bfeea9fe37477d621166675e0ab3ef7...c24ee76b0378950cb16e21f1fb568468892047c4
• Model: gpt-6.1-sol

💡 Click "edited" above to see earlier reviews for this PR.

---

Review Summary

Overall Risk: NONE

No concrete security, correctness, or reliability findings in the authorized PR range.

Findings

No concrete security, correctness, or reliability findings were identified.

Notes

• Review used read-only source and history inspection. Builds, tests, container execution, and network verification were not performed.

---

_{Generated by Codex Security Review |
Requested by: @TheSentinel454 |
Workflow run}