You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 12eec02
Browse filesBrowse the repository at this point in the historyBrowse files
ci(tests): run the container lane beside the QEMU lane on every PR
The container lane landed as an invocable make target that no workflow
referenced, so CI kept running QEMU exclusively and the lane had no run
history on a real runner. Add `E2E (container lane, informational)`,
which installs and runs the same Chainsaw selection against Talos nodes
in containers, on a second runner and against the same commit.
Informational on purpose: the job is absent from e2e-report's `needs`,
so it cannot move the required "E2E Tests" status and a red there does
not block a merge. Every measurement behind the lane was taken on
hand-built spike stands; none on a CI runner.
A separate job rather than a `lane:` matrix leg on `e2e`, because
e2e-report reads `needs.e2e.outputs.soft_red`. A matrixed job publishes
one output map across all legs, so that value would come from whichever
leg finished last and the node-join soft-red decision would turn
nondeterministic. Duplicating a few steps is the cheaper mistake.
Two gaps had to close for the lane to run unattended. The host script
created zpools and loaded modules as the invoking user, which is root on
a dev box but an unprivileged user on a runner, so it now escalates per
command -- never around docker, or the compose project ends up owned by
a different user than teardown runs as. And COZY_APISERVER_ENDPOINT was
read inside the sandbox by nothing that set it; docker exec starts a
fresh environment, so the Makefile passes it through explicitly. Unset
expands to empty and the `:-` default keeps the QEMU lane on .10.
Assisted-By: Claude <[email protected]>
Signed-off-by: Myasnikov Daniil <[email protected]>
Copy file name to clipboardExpand all lines: docs/agents/e2e-testing.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -200,6 +200,8 @@ Today the sandbox boots three QEMU guests and Cozystack runs KubeVirt inside the
200
200
201
201
Three properties of container mode drive the whole design, and each one fails quietly rather than loudly if ignored. `machine.kernel.modules` is a **silent no-op** — `kernel_module_spec.go` returns early on `ModeContainer` with no error and no event — so the host must load `openvswitch` and `zfs` before the nodes start, and both the host script and the BATS file assert it rather than trusting it. Docker gives a privileged container its **own tmpfs `/dev`, seeded once at creation**, so `/dev/kvm` works but ZFS zvols created later never appear and linstor-csi fails `ControllerPublishVolume`; the compose file binds the host devtmpfs instead, which is also why `talosctl cluster create docker` can never carry LINSTOR. And container mode has **no ARP VIP**, so `192.168.123.11` stands in for the QEMU lane's `192.168.123.10` and `hack/e2e-install-cozystack.bats` takes the endpoint from `COZY_APISERVER_ENDPOINT`, defaulting to the unchanged QEMU value.
202
202
203
+
In CI the lane runs as its own job, `E2E (container lane, informational)` in `.github/workflows/pull-requests.yaml`, on a second runner beside the QEMU `e2e` job and against the same commit. It is deliberately absent from `e2e-report`'s `needs`, so it cannot move the required `E2E Tests` status and a red there never blocks a merge -- correct until the lane has a run history, since every measurement behind it was taken on hand-built spike stands rather than a CI runner. It is a separate job rather than a `lane:` matrix leg on `e2e` because `e2e-report` reads `needs.e2e.outputs.soft_red`, and a matrixed job publishes one output map across all legs, which would make the node-join soft-red decision depend on whichever leg finished last. The two lanes take different runners, so they are not a controlled A/B on hardware; `make apply` records the host's `svm features:` on both, which is what lets results be compared within the `vgif`-present and `vgif`-absent strata separately, the way cozystack#3513 itself was established.
204
+
203
205
The nodes run as **siblings on the runner's docker daemon**, not nested inside the sandbox, because those host binds have to resolve against the real host devtmpfs. That is why provisioning is two steps: `hack/e2e-container-up.sh`does the host-side half and needs a docker socket, then the sandbox is attached to the compose network and `hack/e2e-prepare-cluster-container.bats` runs inside it exactly as the QEMU lane's file does.
204
206
205
207
What the lane gives up is **DRBD, and with it more than the `replicated` StorageClass**. DRBD's resource registry is global per kernel, so three containers sharing one kernel cannot represent three DRBD nodes — a second `new-resource` for the same name returns success while changing nothing, which is worse than an error because LINSTOR then records a replica it does not have. It applies to kind equally; it is a property of one kernel, not of Talos. `linstor` must therefore run with `drbd.enabled: false`, without which every satellite CrashLoops and no PVC binds at all. Because linstor-csi couples RWX to DRBD, tenant worker disks become RWO and **live migration is unavailable on this lane** — a larger loss than the missing StorageClass and the reason the QEMU lane must not be retired from nightly coverage. Everything else survives: kube-ovn runs the real OVS dataplane, and LINSTOR keeps real ZFS pools and the production `local` StorageClass.
0 commit comments