On Fri, Feb 12, 2021 at 04:16:49PM +0100, Max Reitz wrote: > From the cancel message, it is not entirely clear why this parameter is > mandatory now, or that it will be optional in the future. Add such a > more detailed explanation as a comment in the test source file. > > Suggested-by: Alex Bennée <alex.ben...@linaro.org> > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > I’ve uploaded a build of Linux 5.10 here: > https://xanclic.moe/linux-5.10 > > But I’ve decided against mentioning it in this new comment or the cancel > message, because, well, it’s my private server and I have limited > bandwidth. > --- > tests/acceptance/virtiofs_submounts.py | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/tests/acceptance/virtiofs_submounts.py > b/tests/acceptance/virtiofs_submounts.py > index 949ca87a83..9a69b6b17b 100644 > --- a/tests/acceptance/virtiofs_submounts.py > +++ b/tests/acceptance/virtiofs_submounts.py > @@ -228,6 +228,18 @@ class VirtiofsSubmountsTest(BootLinux): > def setUp(self): > vmlinuz = self.params.get('vmlinuz') > if vmlinuz is None: > + """ > + The Linux kernel supports FUSE auto-submounts only as of 5.10. > + boot_linux.py currently provides Fedora 31, whose kernel is too > + old, so this test cannot pass with the on-image kernel (you are > + welcome to try, hence the option to force such a test with > + -p vmlinuz=''). Therefore, for now the user must provide a > + sufficiently new custom kernel, or effectively explicitly > + request failure with -p vmlinuz=''. > + Once an image with a sufficiently new kernel is available > + (probably Fedora 34), we can make -p vmlinuz='' the default, so > + that this parameter no longer needs to be specified. > + """ > self.cancel('vmlinuz parameter not set; you must point it to a ' > 'Linux kernel binary to test (to run this test with > ' \ > 'the on-image kernel, set it to an empty string)') > -- > 2.29.2 >
Hi Max, This looks good to me, and I've also tested your kernel build and works like a charm. As further work on top of this, it may be beneficial to have test documentation in a predictable place. The possibilities that come to my mind: * docs/devel/testing.rst * tests/acceptance/$test_file.py/data/README On a different topic, the "https://avocado-project.org/data/assets"; has enough bandwidth and can be used to hold this type asset. Alternatively, we can add a bit more automation to this test by letting people do something like: $ avocado assets register virtiofs-auto-submounts-vmlinuz /path/to/vmlinuz And on the test: vmlinuz = self.fetch_asset('virtiofs-auto-submounts-vmlinuz') And the test should cancel if that asset has not been previously registered. Anyway, Reviewed-by: Cleber Rosa <cr...@redhat.com>
signature.asc
Description: PGP signature
