kola: Support the Debian autopkgtest reboot API#1528
kola: Support the Debian autopkgtest reboot API#1528openshift-merge-robot merged 1 commit intocoreos:masterfrom
Conversation
cgwalters
force-pushed
the
autopkgtest-reboot
branch
from
ceed1c1 to
d8a801d
Compare
|
OK now extended with some infrastructure to more e2e-validate the test infrastructure and also run that autopkgtest reboot example, until such time as we start using that API for other tests. |
cgwalters
force-pushed
the
autopkgtest-reboot
branch
from
d8a801d to
dc3e2ca
Compare
|
Any high level feedback here? |
|
|
||
| // These are defined by https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst | ||
| const ( | ||
| autopkgTestRebootPath = "/tmp/autopkgtest-reboot" |
There was a problem hiding this comment.
Hmm, why not e.g. /usr/local/bin? And that way we don't have to re-write it on each boot either.
There was a problem hiding this comment.
That path is part of the autopkgtest specification.
| #!/bin/bash | ||
| # Copy of the reboot example from https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst | ||
| set -xeuo pipefail | ||
| case "${AUTOPKGTEST_REBOOT_MARK:-}" in |
There was a problem hiding this comment.
Bikeshed: WDYT about just KOLA_REBOOT_MARK? It's good to know that the concept comes from Debian's autopkgtest, though it seems cleaner to have all the env vars exposed consistently start with KOLA_.
There was a problem hiding this comment.
Similarly, the variable is part of the spec. I think using exactly the API from autopkgtest is valuable because it helps us more easily consume existing test suites.
|
Overall concept WFM |
As I was working on extending some of ostree's destructive test suite to do reboots: ostreedev/ostree#2127 I realized that the Debian autopkgtest API for rebooting is better, because it allows *saving state external to the host*. Rather than having the test count boots as ostree is doing today, the "mark" allows us to more reliably dispatch. And further, becase we don't rely on writing anything to disk on the target, we can add clean support for "forced reboots" that might kill the OS before we write to persistent storage there. The "between reboot" state lives in the test runner's memory instead. We retain support for the previous (two!) reboot APIs here for now. I tested this with basically the example script from the Debian autopkgtest specification: ``` set -xeuo pipefail case "${AUTOPKGTEST_REBOOT_MARK:-}" in "") echo "test beginning"; /tmp/autopkgtest-reboot mark1 ;; mark1) echo "test in mark1"; /tmp/autopkgtest-reboot mark2 ;; mark2) echo "test in mark2" ;; *) echo "unexpected mark: ${AUTOPKGTEST_REBOOT_MARK}"; exit 1;; esac echo "ok autopkgtest rebooting" ``` I think it will make sense actually to implement more of the autopkgtest API - Debian has a nontrivial number of tests using this, and I think there's even work upstream in e.g. systemd to bridge its tests to autopkgtest. Which would mean we gain "run systemd's tests in kola" for free.
cgwalters
force-pushed
the
autopkgtest-reboot
branch
from
dc3e2ca to
d571851
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arithx, cgwalters, jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
See coreos/coreos-assembler#1528 I think we can drop the old cosa reboot APIs after this, though I've already forgotten where else I might have written tests using it.
5 participants
As I was working on extending some of ostree's destructive
test suite to do reboots:
ostreedev/ostree#2127
I realized that the Debian autopkgtest API for rebooting is
better, because it allows saving state external to the host.
Rather than having the test count boots as ostree is doing
today, the "mark" allows us to more reliably dispatch.
And further, becase we don't rely on writing anything to disk
on the target, we can add clean support for "forced reboots"
that might kill the OS before we write to persistent storage there.
The "between reboot" state lives in the test runner's memory instead.
We retain support for the previous (two!) reboot APIs here for now.
I tested this with basically the example script
from the Debian autopkgtest specification:
I think it will make sense actually to implement more of the autopkgtest
API - Debian has a nontrivial number of tests using this, and I
think there's even work upstream in e.g. systemd to bridge its
tests to autopkgtest. Which would mean we gain "run systemd's tests in kola"
for free.