e2e: distill common test functionality to lib/test.bash. - #768
Merged
askervin merged 31 commits intoAug 28, 2026
Conversation
lib/test.bash.
klihub
force-pushed
the
refactor/e2e/distill-common-functionality
branch
from
August 26, 2026 14:36
9393859 to
2a55cde
Compare
klihub
marked this pull request as ready for review
August 26, 2026 18:04
kad
reviewed
Aug 26, 2026
klihub
force-pushed
the
refactor/e2e/distill-common-functionality
branch
2 times, most recently
from
August 27, 2026 08:09
2c5b21b to
fe1f434
Compare
There was a problem hiding this comment.
Pull request overview
Refactors E2E tests to centralize reusable test operations in lib/test.bash, reducing duplicated shell logic across topology-aware and balloons suites.
Changes:
- Adds shared helpers for cleanup, polling, logging, resources, CPU/IRQ operations, and policy lifecycle.
- Migrates existing E2E tests to the shared helpers.
- Adds shared Python verification helpers and documents the testing API.
Reviewed changes
Copilot reviewed 61 out of 62 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
.gitignore |
Ignores Python cache directories. |
test/e2e/README.md |
Documents shared test helpers. |
test/e2e/run.sh |
Adds configuration and Helm helpers. |
test/e2e/run_tests.sh |
Loads the shared test library. |
test/e2e/lib/vm.bash |
Adds CPU, kubelet, and reboot helpers. |
test/e2e/lib/test.bash |
Introduces the shared E2E helper library. |
test/e2e/policies.test-suite/py_consts.var.py |
Adds shared memory-locality verification. |
test/e2e/policies.test-suite/balloons/verify.source.sh |
Removes superseded metrics helpers. |
test/e2e/policies.test-suite/balloons/nrt.source.sh |
Removes superseded NRT helpers. |
test/e2e/policies.test-suite/balloons/…/s8c4k/test01-sparse-4kcpus/code.var.sh |
Uses shared hot-plug and NRT helpers. |
test/e2e/policies.test-suite/balloons/n6-hbm-cxl/test01-memory-types/code.var.sh |
Uses shared memory verification. |
test/e2e/policies.test-suite/balloons/n6-hbm-cxl/test04-nrt/code.var.sh |
Uses shared NRT helpers. |
test/e2e/policies.test-suite/balloons/n6-hbm-cxl/py_consts.var.py |
Defines memory-node mappings. |
test/e2e/policies.test-suite/balloons/n4c16/test01-basic-placement/code.var.sh |
Centralizes lifecycle and cleanup. |
test/e2e/policies.test-suite/balloons/n4c16/test02-prometheus-metrics/code.var.sh |
Uses shared metrics and lifecycle helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test03-reserved/code.var.sh |
Centralizes namespace cleanup. |
test/e2e/policies.test-suite/balloons/n4c16/test04-groupby/code.var.sh |
Centralizes lifecycle and namespace handling. |
test/e2e/policies.test-suite/balloons/n4c16/test05-namespace/code.var.sh |
Uses shared namespace helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test06-update-config/code.var.sh |
Centralizes cleanup and cache removal. |
test/e2e/policies.test-suite/balloons/n4c16/test07-maxballoons/code.var.sh |
Uses launch-failure helper and fixes messages. |
test/e2e/policies.test-suite/balloons/n4c16/test08-numa/code.var.sh |
Uses policy relaunch helper. |
test/e2e/policies.test-suite/balloons/n4c16/test09-isolated/code.var.sh |
Uses policy relaunch helper. |
test/e2e/policies.test-suite/balloons/n4c16/test10-allocator-opts/code.var.sh |
Centralizes cleanup and relaunch. |
test/e2e/policies.test-suite/balloons/n4c16/test11-match-expression/code.var.sh |
Centralizes cleanup and relaunch. |
test/e2e/policies.test-suite/balloons/n4c16/test13-cacheclusters/code.var.sh |
Centralizes relaunch and cache cleanup. |
test/e2e/policies.test-suite/balloons/n4c16/test15-loadclasses/code.var.sh |
Uses shared NRT and cleanup helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test16-composite-balloons/code.var.sh |
Uses shared NRT querying. |
test/e2e/policies.test-suite/balloons/n4c16/test17-cstates-scheduling/code.var.sh |
Reuses CPU and scheduling helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test18-turbo-priority/code.var.sh |
Reuses logging and configuration helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test19-pct/code.var.sh |
Reuses logging, resources, and Helm helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test20-config-status/code.var.sh |
Uses shared status polling. |
test/e2e/policies.test-suite/balloons/n4c16/test21-controller-check/code.var.sh |
Uses shared instrumentation URL. |
test/e2e/policies.test-suite/balloons/n4c16/test22-isolcpus/code.var.sh |
Reuses reboot and isolation helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test23-available-cpus/code.var.sh |
Centralizes lifecycle and namespaces. |
test/e2e/policies.test-suite/balloons/n4c16/test24-podresources/code.var.sh |
Reuses log and resource polling. |
test/e2e/policies.test-suite/balloons/n4c16/test25-irq/code.var.sh |
Reuses CPU and interrupt helpers. |
test/e2e/policies.test-suite/balloons/n4c16/test30-numa-disabled/code.var.sh |
Reuses NUMA lifecycle helpers. |
test/e2e/policies.test-suite/topology-aware/s8c4k/test01-sparse-4kcpus/code.var.sh |
Uses shared hot-plug helpers. |
test/e2e/policies.test-suite/topology-aware/n6-hbm-cxl/test01-memory-types/code.var.sh |
Uses shared memory verification. |
test/e2e/policies.test-suite/topology-aware/n6-hbm-cxl/test04-nrt/code.var.sh |
Uses shared NRT helpers. |
test/e2e/policies.test-suite/topology-aware/n6-hbm-cxl/py_consts.var.py |
Defines memory-node mappings. |
test/e2e/policies.test-suite/topology-aware/n4c128/test19-cacheclusters/code.var.sh |
Extracts repeated cache-filling loops. |
test/e2e/policies.test-suite/topology-aware/n4c16/test00-basic-placement/code.var.sh |
Centralizes cleanup and kernel reset. |
test/e2e/policies.test-suite/topology-aware/n4c16/test05-reserved-resources/code.var.sh |
Uses cleanup and launch-failure helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test07-mixed-allocations/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test08-cpuprio-allocation/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test09-container-exit/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test10-additional-reserved-namespaces/code.var.sh |
Uses namespace and pod helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test11-reserved-cpu-annotations/code.var.sh |
Consolidates pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test12-config-status/code.var.sh |
Uses shared status polling. |
test/e2e/policies.test-suite/topology-aware/n4c16/test13-reject-symlink/code.var.sh |
Reuses failure and logging helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test14-burstable/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test14-global-shared-preference/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test15-busy-shared-pools/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test16-idle-shared-pools/code.var.sh |
Uses shared pod cleanup. |
test/e2e/policies.test-suite/topology-aware/n4c16/test17-scheduling-classes/code.var.sh |
Reuses scheduling and namespace helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test18-strict-alignment/code.var.sh |
Reuses container-error verification. |
test/e2e/policies.test-suite/topology-aware/n4c16/test19-cpuclass/code.var.sh |
Reuses CPU-class and logging helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test25-irq/code.var.sh |
Reuses interrupt and error helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test30-numa-disabled/code.var.sh |
Reuses NUMA lifecycle helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test31-duplicate-disambiguation/code.var.sh |
Reuses cleanup and plugin-log helpers. |
test/e2e/policies.test-suite/topology-aware/n4c16/test40-otel-logging/code.var.sh |
Uses shared pod cleanup. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
klihub
force-pushed
the
refactor/e2e/distill-common-functionality
branch
2 times, most recently
from
August 28, 2026 10:41
ddd69c6 to
194b93d
Compare
Test cases re-implement the same helper functions over and over again,
often in subtly different variants. Add a library for lifting those out
into shared helpers, together with the polling helper which most of them
turn out to need.
The library is not sourced by run.sh. Instead, run_tests.sh seeds the
*.source.sh chain with it, which means that
- the helpers are sourced into the same subshell that evaluates the
test case code and nowhere else, so they cannot clash with the
script API of run.sh, and
- any *.source.sh file can override a helper defined in the library,
as those are sourced after it.
run.sh still reads the library, but only to scrape the documentation of
the helpers for "run.sh help".
retry-until is the host side counterpart of vm-run-until: it evaluates a
snippet until it succeeds instead of running a command in the VM. Nine
test cases hand-roll that loop with different variable names, different
off-by-one behaviour, and in one case with a retry counter which is never
incremented. Unlike those loops it never fails the test by itself, so
that callers can choose between error, command-error and tolerating the
timeout.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Thirty test cases define a cleanup function, and they are all built from the same handful of primitives: delete all pods, delete named pods in a namespace, create and delete a list of namespaces, and remove the cache file of the policy. The variants differ mostly in whether they tolerate errors, which is accidental rather than intentional. The helpers pass --ignore-not-found and never fail, so tests no longer need to sprinkle "|| true", "|| :" and "return 0" around them, and calling cleanup at the beginning of a test no longer logs errors about pods and namespaces which are not there yet. kill-test-processes brackets the space in its pkill patterns. Without that, "pkill -9 -f 'echo pod'" also matches the command line of the shell which runs it, and kills it. That is what the cleanup of test31-duplicate-disambiguation used to do. Only cleanup and teardown call sites are converted. Pod deletions in the middle of a test are part of the scenario, and deliberately keep failing if the pod is not there. The awk based pod selection of the fuzz tests is not expressible with the helpers and is left as it is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Three tests expect launching the plugin to fail, and each of them spells out the same subshell, expect_error and launch_timeout incantation, plus an error for the case where the launch unexpectedly succeeds. In test13-reject-symlink this also collapses the surrounding exit status dance: the only reason for the subshell and the numeric statuses was to get the failure out of the subshell which the cache restoring trap needed. An EXIT trap in the test itself does the same, and the test code already runs in a subshell of its own. test07-maxballoons expected the failure without setting expect_error, so it relied on helm-launch calling error, and logged a confusing error of its own before reporting success. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Both test18-turbo-priority and test19-pct define it. The copy in test19-pct returned the status instead of failing the test, but it has no callers, so take the one which fails the test. Poll in the VM with vm-run-until instead of from the host, so that waiting takes one ssh round trip rather than one per attempt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Three tests verify that the plugin refuses to create a container, and each of them repeats the same three steps: wait for the container to enter the CreateContainerError state, fetch its state, and grep the state for the expected error. That is twelve copies of the same block, plus two copies of a wait function which differ only in whether they address the container by name or by index. container-state accepts both, so the same helpers serve all the call sites. The regular expressions are matched with basic grep, as before. One of the patterns in test25-irq relies on parentheses being literal, so matching them as extended regular expressions would silently stop the pattern from matching what it is supposed to match. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Eight tests read the log of the plugin daemonset, each of them spelling out the kubectl command with a hardcoded daemonset name. plugin-log derives the daemonset from $POLICY the same way helm-launch does, and returns the status of matching the pattern, so that callers can keep reporting a missing log line themselves. It also retries while the log is not available yet, which happens right after the plugin has restarted. This drops pull-logs from test31-duplicate-disambiguation. Its retry counter was never incremented, because it added one to $ctn instead of $cnt, so it kept retrying until the logs became available rather than giving up after five attempts. The retry it really needs, that is, re-running the whole scenario when no remapping was triggered, is in check-logs and stays as it is. The tests which also assert something about the log are converted separately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
test19-pct, test19-cpuclass and test18-turbo-priority each define their own function for fetching the tail of the log lines of the subsystem they test, and the first two also define near-identical assertions on top of it. The only real difference between the three is which log lines they are interested in, so keep that in the tests as plugin_log_filter and share everything else. The signatures of the assertions are unchanged, so their 27 call sites stay as they are. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
test19-pct and test19-cpuclass have identical functions for reading and waiting for an extended resource of the node, and test24-podresources waits for one by grepping the output of kubectl describe node in a hand-rolled 60 round loop. Reading the value with jq also makes the comparison in test24-podresources exact: it used to accept any allocatable amount of tech.com/tpu containing a 4. test19-pct keeps thin wrappers of its own, so that the name of the resource it polls stays in one place. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Both test25-irq tests carry byte-identical copies of expand-cpulist and ids-difference, and test19-cpuclass a third copy of expand-cpulist. Two of the copies pass their arguments through expand-cpulist first, so they accept both the compact and the expanded form, while the balloons copies only accept one form each. Keep the permissive behaviour. ids-difference is renamed to cpulist-difference to say what it operates on, since it now lives next to expand-cpulist in the shared library. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
klihub
force-pushed
the
refactor/e2e/distill-common-functionality
branch
from
August 28, 2026 11:09
194b93d to
91ed1ad
Compare
askervin
reviewed
Aug 28, 2026
Four tests look up which CPUs a container is allowed to run on, using two fundamentally different mechanisms: two of them read the live cpuset from inside the container with kubectl exec, and two read it from the snapshot which "report allowed" took. The two are not interchangeable, so keep both under names which say which one they are, and convert each test to the mechanism it already used. container-cpus also gets working error handling. Both kubectl exec copies tested $? after a pipeline, so they checked the exit status of cut rather than that of ssh and kubectl, and never reported anything. allowed-cpu-ids returns the ids sorted, which the copy in test17-cstates-scheduling did not. The test uses them as a set, so this only makes its output deterministic. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The two test25-irq tests are the pair with the most duplication in the suite. Together with the CPU list and cpuset helpers already lifted out, this shrinks them from 551 to 307 lines. The two copies of verify-irq-cpus differ in that the balloons one takes an interrupt number, which the test resolves from /proc/interrupts with awk of its own, while the topology-aware one takes a pattern and resolves it itself. Keep resolve-irq, which accepts both, and let the balloons test name its interrupts by pattern too. resolve-irq now also rejects a match which is not an interrupt number. A pattern matching no interrupt used to fall through to matching the header line of /proc/interrupts, and resolved to the concatenation of its CPU column titles instead of reporting that there is no such interrupt. set-irq-cpus is not lifted out. It had no callers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Both test17 tests define verify-sched. The topology-aware copy is the stricter one: it fails if the expected policy or priority is not given, instead of silently verifying nothing, and it drops the uninteresting lines of /proc/PID/sched from the output. Keep that one. The balloons test spelled the expected policies as bare numbers with the name in a comment. It now uses the same SCHED_* constants which the topology-aware test defined for itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
test20-config-status and test12-config-status are the same test for two different policies, and both spell out the jsonpath of the node status, the kubectl wait, and the status dump for the failure case. Three more blocks in test19-cpuclass check the errors in the status the same way. The helpers go to run.sh next to get-config-node-status-result and its relatives, which already know how to address the configuration resource of a policy, rather than into lib/test.bash where they would start a second, parallel API for the same thing. They also address the node like the rest of that family does, with get-hostname-for-vm, instead of using $VM_HOSTNAME directly. The two differ if the hostname of the VM has a domain part. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
test19-pct reconfigures a running plugin in place with a helm upgrade, and to do that it repeats the whole --set argument list of helm-launch. Factor that list out as helm-set-args, so that helm-launch and the new helm-reconfigure cannot drift apart, and drop the copy from the test. test18-turbo-priority patches the configuration custom resource of the policy five times, each time naming the resource explicitly and adding its own error handling. patch-policy-config derives the resource from $POLICY like the other configuration helpers in run.sh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Three tests assert that the plugin associated CPUs to a CLOS, and two that it enforced the frequencies of a CPU class, each of them spelling out the log line the plugin writes. That is the log format of the cpu control knowing in eleven places what it should know in one. The rest of the CPU frequency assertions stay in the tests which use them. The enforce write counting and windowing in test18-turbo-priority and the c-state override checks in test17-cstates-scheduling have a single user each, and encode what that test means by a minimal set of writes rather than anything reusable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
test22-isolcpus and test00-basic-placement both set or clear isolcpus on the kernel command line, reboot, verify the result and restart kubelet, and the two test30-numa-disabled tests share their whole NUMA disabling prologue and epilogue apart from the policy name. vm-restart-kubelet waits with wait-for-node-ready instead of waiting for the kube-apiserver process and then for cilium. Waiting for the node to become Ready covers both, and does not assume that the CNI plugin of the VM is cilium, which is only one of the alternatives provisioning supports. The two test30 tests are now identical, and the policy they check for after the reboot comes from $POLICY. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
nrt.source.sh was scoped to the balloons policy, so test16-composite-balloons defined a verify-nrt of its own and test15-loadclasses inlined a query for its debug output, both addressing the topology of the node as the first item of a list. Express all three on nrt-query, which addresses the topology of the node the way nrt.source.sh already did. The tests outside n4c16 which use nrt-verify-zone-attribute, nrt-verify-zone-resource and $nrt_kubectl_get need no changes: the library is sourced at the same point of the same chain, only before the *.source.sh files rather than as one of them. Also fix two message bugs which came along: the expected value was missing from the failure message of nrt-verify-zone-attribute, which referred to a variable that never existed, and the resource name was missing from the progress message of nrt-verify-zone-resource. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
verify.source.sh was scoped to the balloons policy although nothing in it is balloons-specific: it just reads the metrics endpoint of the instrumentation server, which any plugin can be configured to open. The URL of that server was also hardcoded in test21-controller-check, which reads another endpoint of it, so give it a name of its own. The curl commands now pass --noproxy localhost, as the ones in test21-controller-check already did. Without it, a run which sets a proxy for the VM tries to reach the plugin through the proxy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The failure messages of the second allocation failure check refer to pod6, but the pod the check creates is pod5. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Restarting the plugin with a new configuration is the most repeated pair of commands in the suite. Give it a name. Converted are the 27 sites which name their configuration file, where the one-liner also reads better than the pair it replaces. The sites which build their configuration with instantiate keep the two lines: passing a command substitution through a quoted argument would not make them any clearer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
List the helper groups of lib/test.bash in the README, so that the next test does not have to grep the library to find out what is already there, and note the variables which configure them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The test defines cleanup but never calls it. It deletes both of its pods as part of the scenario, so calling it at the end would be a no-op anyway. Note that the test also never terminates the plugin it launched. That is left as it is, since every test starts by terminating a previously running one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
All four non-fuzz tests of the two n6-hbm-cxl collections start with the same cleanup function, and test01-memory-types with the same terminate and launch pair, as the n4c16 tests did. The awk based pod selection of test02-fuzz-memallocs is not expressible with the helpers and is left as it is, like its n4c16 counterpart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
topology-aware/test04-nrt carried its own copy of the kubectl command and of the zone attribute assertion, predating the shared ones. The two copies differ in that the shared assertion matches a regular expression while this one compared for equality, so anchor the patterns of the converted call sites to keep the comparisons exact. Unanchored, three of them would have accepted a superset: "3" would match a reserved cpuset of "13" or "3-5". The regular expression is what the balloons test needs, where the expected value is a genuine alternation of the cpusets the policy may pick, so the two cannot be merged the other way around. Both tests print the topology for debugging, four times in total, which is now nrt-dump. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Both test01-memory-types tests verify that a container uses a given set of memory types, and both spell out the same conditional twenty-one times in total: compare the memory nodes of the container against the nodes of package 0, or against those of package 1 if the container does not run in package 0. local_mems() states the same thing as the memory types it expects, which is what the annotation under test asks for, and keeps the mapping from a memory type to a memory node in one place per topology. It also reports what went wrong. The conditional only ever evaluated to False, leaving it to the reader of the log to work out which package the container ended up in and which nodes that means. Test suite level py_consts.var.py is a new file. run_tests.sh appends py_consts across all levels, so the helper lands before the topology level definitions it uses, which is fine as Python resolves them when the helper runs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Both s8c4k tests open with a byte-identical 39 line prologue which prepares the sparse 4k CPU topology. Start distilling it by lifting out the sysfs details of hot-plugging. vm-cpus-enabled replaces a grep for the literal "511,1535,4095" in the list of enabled CPUs, which only worked because the three CPUs happen to be listed next to each other. It expands the list and checks each CPU separately, so it also works for CPUs which the kernel reports as part of a range. Onlining the hot-plugged CPUs is now followed by vm-restart-kubelet, which also waits for the node to become ready, instead of restarting kubelet without waiting for anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The rest of the shared prologue of the two s8c4k tests: a kernel version requirement, waiting for kubelet to report the hot-plugged CPUs in the capacity of the node, and a check that the root cgroup of the pods can use them. Together with the hot-plug helpers this shrinks the prologue from 39 lines to 22. Waiting for the capacity needs no helper of its own, wait-node-resource does it. That also makes the comparison exact: the old check grepped the capacity for a 6, which a capacity of 16 or 64 would have satisfied too. verify-kubepods-cpus likewise expands the cpuset instead of grepping it for each CPU as a substring, so a cpuset of 40950 no longer counts as having CPU 4095. It handles both the single and the multiple cpuset file cases, which differ in whether grep prefixes its output with file names. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
relaunch-policy, wait-pod-gone and delete-pods, for the same reasons as in the other test collections. The two pod deletions which are steps of the topology-aware scenario, not teardown, are left as they are: they should keep failing if the pod is not there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The same cleanup function and the same terminate and launch pair as everywhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The test fills every L3 cache with a burstable pod three times over, and each time spells out the same loop and the same pair of assertions about the result. The 127 usable CPUs of the node were a magic number in three places. The helpers stay in the test. They are specific to what it does, and no other test needs them. The annotation itself stays spelled out at the call sites which set it per container. Annotation keys are the interface under test, and keeping them literal is what makes it possible to find the tests which cover a given annotation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
The cleanup function came from test18-strict-alignment, which in turn copied it from test17-scheduling-classes, the only test which creates the highprio and lowprio namespaces. In n4c16 the deletion still has a point: test17 and test18 run on the same VM, so test18 cleans up after a test17 which failed before its own cleanup. There is no such test in the n4c128 collection, and no balloons n4c128 collection to share the VM with, so nothing ever creates those namespaces there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
klihub
force-pushed
the
refactor/e2e/distill-common-functionality
branch
from
August 28, 2026 12:15
91ed1ad to
a3c525a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch set refactors existing test cases by
lib/test.bash,The PR is split to commits to "identify one refactorable function or functions related to the same test or same functionality to be tested, distill out common functionality, then refactor the affected tests to use the new common functions, putting each such change to a separate commit". Moreover, separate sweeps over the
n4c16,n4c128,n6-hbm-cxl, ands8c4ktopology test sets are split to separate commits.Here is the summary of logical changes made.
The full test set still passes after these changes.