Package: autopkgtest
Version: 5.5
Severity: wishlist
Hi,
I'm thinking of adding autopkgtests to src:nbd.
One thing which the nbd-client package adds is initramfs hooks for
supporting root-on-NBD. To do that, you need:
- A machine on the network running nbd-server
- A machine running the initramfs hooks, with kernel command-line
parameters like "nbdroot=1.2.3.4:nbexport root=/dev/nbd0"
The second machine can then run diskless.
This is not possible with the current architecture of autopkgtest. I've
given this some thought, and came up with the following, which I think
strikes a balance between "little work needed to make basic usage of
this possible", and "flexible enough to allow for future extensibility".
The following demonstrates the idea I have in mind:
---8<---
Test-Skeleton:
create testbed1
create testbed2
start-test testbed1 test1
start-test testbed2 test2
end-test testbed2
set testbed1 VAR=$(ip ad sh | ...)
start-test testbed2 test3 $VAR
end-test testbed2
end-test testbed1
kill testbed1
kill testbed2
Restrictions: multihost
Tests: test1
Restrictions: multihost-guest, breaks-testbed
Tests: test2
Tests: test3
Features: takes-variable
--->8---
This adds two restrictions and a variable, and creates a DSL that is
meant to be run by way of the "Test-Skeleton" header:
- The "multihost" restriction means to say that it isn't actually a test
which is run directly, but that it's a "meta" test in the test suite.
It requires the "Test-Skeleton" thing to mark that we're using the DSL
here (but I guess we can do without that if that would make sense).
The DSL would know the following things:
- "create": creates a testbed. If multiple testbeds are created in
this manner, they must be connected to eachother on a (virtual or
physical) network. Probably we might want to extend this command
later on to specify the layout of the network etc, but for now that
probably shouldn't be required.
- "start-test": starts a "guest" test in a given testbed, but does not
wait for it to end (probably shouldn't be allowed to recurse).
- "end-test": waits for the test that was started earlier in a given
testbed to end. If that test returned failure, fail the whole test
(and abort, probably). If it succeeded, we move on. If no test was
running there, should probably error?
- "set": runs an arbitrary command in a given testbed, captures the
output (probably stdout only), and assigns it to a variable.
- "kill": destroys a testbed. If a test is still running, the result
of that test is ignored.
- The "multihost-guest" restriction means to say that this particular
test makes no sense at all unless it's run as part of the multihost
test defined elsewhere.
- The "takes-variable" feature, to say that it optionally takes a
parameter.
There are no loops or conditionals here; that is on purpose. I don't
think this needs to be a Turing-complete language; if a test needs to
loop or test a condition, then that should be done in one of the tests
that is actually being run on one of the testbeds.
With that, in the above example, the "test1" test could configure the
system so that a server is running there, which can then be used by the
other tests that run in the other testbed. To discover on which address
the other testbed is running, the "host" test can run commands there
which assign variables, and then "guest" tests can use that output to do
"something useful" with them. This can be used for passing on network
configuration things, but it could also be used for other things; e.g.,
randomly-generated credentials could be passed from one testbed to the
other.
Thoughts?
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'),
(500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, m68k, arm64
Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autopkgtest depends on:
ii apt-utils 1.6.4
ii libdpkg-perl 1.19.0.5
ii procps 2:3.3.15-2
ii python3 3.6.6-1
ii python3-debian 0.1.33
Versions of packages autopkgtest recommends:
ii autodep8 0.14
Versions of packages autopkgtest suggests:
pn lxc <none>
pn lxd-client <none>
ii ovmf 0~20180812.cb5f4f45-1
ii qemu-efi-aarch64 0~20180812.cb5f4f45-1
pn qemu-efi-arm <none>
ii qemu-system 1:2.12+dfsg-3
ii qemu-utils 1:2.12+dfsg-3
ii schroot 1.6.10-5
-- no debconf information
