[Tech Debt]: Verify tps server packages (netperf, python3) install cleanly in CI

[mrhillsman]

Category

Missing tests

Description

The tps workload's server-side cloud-init declares Packages: []string{"netperf", "python3"} and RunCmd enables the systemd service that depends on both. If either package is missing or fails to install on the base Fedora image (or in the golden image), the server never comes up and the client systemd unit will retry forever against a DNS name that never resolves successfully.

Today there is no automated coverage that asserts these packages install on the actual container disk image used in production.

Severity

Low — cosmetic or minor inconvenience

Affected Files

• internal/workloads/tps.go — buildServerUserdata package list
• build/golden-image/Containerfile — pre-installs netperf and python3; verify this remains true on rebuild
• E2E test coverage (currently no test asserts tps server reaches Running and serves)

Proposed Fix

Two layers:

1. Pre-install in the golden image. Already done for netperf and python3 in build/golden-image/Containerfile — add a smoke test in the golden-image build pipeline that runs rpm -q netperf python3 fio iperf3 stress-ng postgresql-server iproute-tc procps-ng and fails the build if any are missing.
2. E2E coverage for tps end-to-end. Add a tests/e2e/ case that deploys tps, waits for both VMs to be Running, then exec's into the client and asserts non-empty TCP_RR + HTTP iteration output appears in journalctl -u virtwork-tps.service within a generous timeout.

Area

Workloads

Architecture Layer

Layer 3 - Workload Definitions (workloads, registry)