e2e-deploy is the only lane that proves a deploy against real BMC/Redfish hardware end to end. It stands up a real Site-managed tracker (TRACKER_SERVER_IP, pinned through a per-pod ips override) and a real seeder Deployment, then deploys a multi-GiB image onto a KubeVirt VM over BitTorrent.
It contains no tracker assertion at all.
Evidence
assert-tracker-swarm, assert-seeder-announce and assert-seeder-l3 are called from eleven places in .github/workflows/main.yaml — lines 1703, 1801, 1812, 2614, 2620, 2740, 2743, 2746, 2756, 3509, 3658. The e2e-deploy job spans lines 590-1181. None of the eleven falls inside it. Every one belongs to e2e-routed-site, e2e-two-site-concurrent, or e2e-three-machine-concurrent.
The topology permits the failure this matters for. create-provisioning-nads/action.yml says it in its own comment: "Three NADs on the SAME bridge, split on purpose". kezio-boot-network (bootd), kezio-seeder-network (seeder and tracker) and kezio-boot-network-vm (the target VM) all attach to one Linux bridge in 192.0.2.0/24. The target VM, the seeder and the tracker share one L2 multicast domain.
tmp/ezio/app.cpp's make_session_params never sets enable_lsd or enable_dht, so libtorrent's defaults apply and both are on.
The scenario where the lane passes and the claim is false
The agent's BitTorrent client discovers the seeder through libtorrent's Local Service Discovery multicast on the shared bridge and never announces to the tracker. The tracker's log stays at 0 bytes. The seeder serves the content correctly anyway, so verify-deploy's three layers all pass — Machine status, AgentConnected, and the marker token read back through the qemu-guest-agent prove the content landed, and say nothing about how it was delivered.
This is the same mechanism that kept e2e-two-site-concurrent green for dozens of runs while its tracker never participated. That lane got assert-tracker-swarm. This one did not.
Why it matters
e2e-deploy is the lane the project would point at to say the system works. Its most novel piece of infrastructure — the per-Site tracker — is the one piece it never exercises.
Suggested fix
Scrape the tracker for the run's info hash after the deploy, the way assert-tracker-swarm already does, and require a real peer entry. Reaching the assertion's resolution further would need the seeder off the machine's segment, as the three-machine lane does.
e2e-deployis the only lane that proves a deploy against real BMC/Redfish hardware end to end. It stands up a real Site-managed tracker (TRACKER_SERVER_IP, pinned through a per-podipsoverride) and a real seeder Deployment, then deploys a multi-GiB image onto a KubeVirt VM over BitTorrent.It contains no tracker assertion at all.
Evidence
assert-tracker-swarm,assert-seeder-announceandassert-seeder-l3are called from eleven places in.github/workflows/main.yaml— lines 1703, 1801, 1812, 2614, 2620, 2740, 2743, 2746, 2756, 3509, 3658. Thee2e-deployjob spans lines 590-1181. None of the eleven falls inside it. Every one belongs toe2e-routed-site,e2e-two-site-concurrent, ore2e-three-machine-concurrent.The topology permits the failure this matters for.
create-provisioning-nads/action.ymlsays it in its own comment: "Three NADs on the SAME bridge, split on purpose".kezio-boot-network(bootd),kezio-seeder-network(seeder and tracker) andkezio-boot-network-vm(the target VM) all attach to one Linux bridge in192.0.2.0/24. The target VM, the seeder and the tracker share one L2 multicast domain.tmp/ezio/app.cpp'smake_session_paramsnever setsenable_lsdorenable_dht, so libtorrent's defaults apply and both are on.The scenario where the lane passes and the claim is false
The agent's BitTorrent client discovers the seeder through libtorrent's Local Service Discovery multicast on the shared bridge and never announces to the tracker. The tracker's log stays at 0 bytes. The seeder serves the content correctly anyway, so
verify-deploy's three layers all pass — Machine status,AgentConnected, and the marker token read back through the qemu-guest-agent prove the content landed, and say nothing about how it was delivered.This is the same mechanism that kept
e2e-two-site-concurrentgreen for dozens of runs while its tracker never participated. That lane gotassert-tracker-swarm. This one did not.Why it matters
e2e-deployis the lane the project would point at to say the system works. Its most novel piece of infrastructure — the per-Site tracker — is the one piece it never exercises.Suggested fix
Scrape the tracker for the run's info hash after the deploy, the way
assert-tracker-swarmalready does, and require a real peer entry. Reaching the assertion's resolution further would need the seeder off the machine's segment, as the three-machine lane does.