From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v4 3/3] test: Convert build tests to exeter
Date: Wed, 20 Aug 2025 14:13:01 +0200 [thread overview]
Message-ID: <20250820141301.5568a184@elisabeth> (raw)
In-Reply-To: <aKWvTAaL0rMhWi0i@zatzit>
On Wed, 20 Aug 2025 21:19:40 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Aug 20, 2025 at 12:40:44PM +0200, Stefano Brivio wrote:
> > On Wed, 20 Aug 2025 13:10:02 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > On Tue, Aug 19, 2025 at 04:27:54PM +0200, Stefano Brivio wrote:
> > > > On Thu, 7 Aug 2025 21:32:37 +1000
> > > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > > >
> > > > > Convert the tests in build/all to be based on exeter. The new version of
> > > > > the tests is more robust than the original, since it makes a temporary copy
> > > > > of the source tree so will not be affected by concurrent manual builds.
> > > > >
> > > > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > > > ---
> > > > > test/build/all | 61 --------------------------------
> > > > > test/build/build.py | 84 +++++++++++++++++++++++++++++++++++++++++++++
> > > > > test/run | 8 ++---
> > > > > 3 files changed, 88 insertions(+), 65 deletions(-)
> > > > > delete mode 100644 test/build/all
> > > > > create mode 100755 test/build/build.py
> > > > >
> > > > > diff --git a/test/build/all b/test/build/all
> > > > > deleted file mode 100644
> > > > > index 1f79e0d8..00000000
> > > > > --- a/test/build/all
> > > > > +++ /dev/null
> > > > > @@ -1,61 +0,0 @@
> > > > > -# SPDX-License-Identifier: GPL-2.0-or-later
> > > > > -#
> > > > > -# PASST - Plug A Simple Socket Transport
> > > > > -# for qemu/UNIX domain socket mode
> > > > > -#
> > > > > -# PASTA - Pack A Subtle Tap Abstraction
> > > > > -# for network namespace/tap device mode
> > > > > -#
> > > > > -# test/build/all - Build targets, one by one, then all together, check output
> > > > > -#
> > > > > -# Copyright (c) 2021 Red Hat GmbH
> > > > > -# Author: Stefano Brivio <sbrivio@redhat.com>
> > > > > -
> > > > > -htools make cc rm uname getconf mkdir cp rm man
> > > > > -
> > > > > -test Build passt
> > > > > -host make clean
> > > > > -check ! [ -e passt ]
> > > > > -host CFLAGS="-Werror" make passt
> > > > > -check [ -f passt ]
> > > > > -
> > > > > -test Build pasta
> > > > > -host make clean
> > > > > -check ! [ -e pasta ]
> > > > > -host CFLAGS="-Werror" make pasta
> > > > > -check [ -h pasta ]
> > > > > -
> > > > > -test Build qrap
> > > > > -host make clean
> > > > > -check ! [ -e qrap ]
> > > > > -host CFLAGS="-Werror" make qrap
> > > > > -check [ -f qrap ]
> > > > > -
> > > > > -test Build all
> > > > > -host make clean
> > > > > -check ! [ -e passt ]
> > > > > -check ! [ -e pasta ]
> > > > > -check ! [ -e qrap ]
> > > > > -host CFLAGS="-Werror" make
> > > > > -check [ -f passt ]
> > > > > -check [ -h pasta ]
> > > > > -check [ -f qrap ]
> > > > > -
> > > > > -test Install
> > > > > -host mkdir __STATEDIR__/prefix
> > > > > -host prefix=__STATEDIR__/prefix make install
> > > > > -check [ -f __STATEDIR__/prefix/bin/passt ]
> > > > > -check [ -h __STATEDIR__/prefix/bin/pasta ]
> > > > > -check [ -f __STATEDIR__/prefix/bin/qrap ]
> > > > > -check man -M __STATEDIR__/prefix/share/man -W passt
> > > > > -check man -M __STATEDIR__/prefix/share/man -W pasta
> > > > > -check man -M __STATEDIR__/prefix/share/man -W qrap
> > > > > -
> > > > > -test Uninstall
> > > > > -host prefix=__STATEDIR__/prefix make uninstall
> > > > > -check ! [ -f __STATEDIR__/prefix/bin/passt ]
> > > > > -check ! [ -h __STATEDIR__/prefix/bin/pasta ]
> > > > > -check ! [ -f __STATEDIR__/prefix/bin/qrap ]
> > > > > -check ! man -M __STATEDIR__/prefix/share/man -W passt 2>/dev/null
> > > > > -check ! man -M __STATEDIR__/prefix/share/man -W pasta 2>/dev/null
> > > > > -check ! man -M __STATEDIR__/prefix/share/man -W qrap 2>/dev/null
> > > > > diff --git a/test/build/build.py b/test/build/build.py
> > > > > new file mode 100755
> > > > > index 00000000..12bb82d8
> > > > > --- /dev/null
> > > > > +++ b/test/build/build.py
> > > > > @@ -0,0 +1,84 @@
> > > > > +#! /usr/bin/env python3
> > > > > +#
> > > > > +# SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +#
> > > > > +# PASST - Plug A Simple Socket Transport
> > > > > +# for qemu/UNIX domain socket mode
> > > > > +#
> > > > > +# PASTA - Pack A Subtle Tap Abstraction
> > > > > +# for network namespace/tap device mode
> > > > > +#
> > > > > +# test/build/build.py - Test build and install targets
> > > > > +#
> > > > > +# Copyright Red Hat
> > > > > +# Author: David Gibson <david@gibson.dropbear.id.au>
> > > > > +
> > > > > +import contextlib
> > > > > +import os
> > > > > +from pathlib import Path
> > > > > +import subprocess
> > > > > +import tempfile
> > > > > +from typing import Iterable, Iterator
> > > > > +
> > > > > +import exeter
> > > > > +
> > > > > +def sh(cmd):
> > > > > + subprocess.run(cmd, shell=True)
> > > > > +
> > > > > +
> > > > > +@contextlib.contextmanager
> > > > > +def clone_sources() -> Iterator[str]:
> > > > > + os.chdir('..') # Move from test/ to repo base
> > > > > + with tempfile.TemporaryDirectory(ignore_cleanup_errors=False) as tmpdir:
> > > >
> > > > I guess I see the advantage of this syntax, it's still a bit less
> > > > obvious to me than a mere sequence of steps and an explicit cleanup
> > > > function.
> > >
> > > I agree that it's less obvious, but I think the advantages are worth
> > > it. Namely that it will correctly run the cleanup in nearly all cases
> > > of an interrupted test (not a SIGKILL, obviously).
> > >
> > > Arguably, it's not a good trade off in this simple case. However once
> > > we get to real network tests, it's pretty common to have multiple
> > > nested layers of setup, each with their own teardown. Sometimes you
> > > need something torn down, but it's only set up partway through the
> > > test, or you want something for the first part of the test but not
> > > after, so it needs to be torn down only if interrupted at certain
> > > points. Manually keeping track of that quickly becomes really
> > > painful, I really want to use this technique there.
> >
> > Another idea (I'm not sure if it makes this useless, but we probably
> > want to implement it anyway) is what nft tests (and some kselftests) do
> > nowadays: every test runs in its own network namespace, so you don't
> > need an explicit teardown. The kernel already tracks things for you.
>
> Right, I'm planning to implement that in tunbridge. Unlike the
> earlier drafts, my intention is that all the namespaces / whatever you
> explicitly create will be nested inside a top-level sandboxing
> namespace.
Ah, neat. One might probably argue that the top-level sandboxing should
be part of a test runner rather than tunbridge itself, but I guess it's
the only practical choice at the moment.
And this is probably enough complexity at this stage, but eventually, I
was thinking, if instead of a single top-level sandboxing, you allow
several levels of nested sandboxing with some kind of descriptive way
to define it, then...
> I don't think it obviates the use for context managers, though. For
> one thing I think we may have occasional need for things that won't be
> handled by the normal sandbox, but the contextmanager can handle those
> too. More widely, there are cases where you want to tear something
> down partway through normal test operation. The context manager will
> do that neatly, while also doing the teardown if interrupted before
> that point.
...you could take care of this kind of problem as well (at least in
some cases?).
Consider the case where you have a group of tests with some expensive
setup that's in common between them (say, setting up a guest image and
starting a guest... even though eventually I think we should move to
libkrun / virtiofs / muvm and get rid of the test image itself).
The single tests could be network-sandboxed between each other, and
share the same mount namespace and tmpfs. Once a test finishes, its
specific network setup is cleaned up, but you still have the guest
image around and possibly the guest running (if we allow that as a
special sandboxing level).
[counts occurrences of 'killall -9 nstool' in shell history :)] to me
this approach looks more robust / enforcing than context managers, even
though I'm not sure how pervasively it can be used.
> > If you combine that with what pasta does (same as container runtimes
> > really), you could get something that's also robust to SIGKILL, by
> > making every test "parent" process (assuming there can be one) PID 1 in
> > its own PID namespace.
>
> Right, it can sometimes make things more confusing during debugging,
> though.
On that subject, the test contexts stuff you implemented for the
current test framework almost entirely eliminates this confusion, at
least for my usage.
> > Add mount namespaces on top, with tmpfs, and we probably don't even
> > need to clean up after ourselves in build tests.
> >
> > Yes, it could be called a container but it's probably useful to retain
> > tight control of what namespace we detach and when.
> >
> > Given that pasta(1) is now available on any distribution where you
> > might reasonably find Python, by the way, you could consider using it
> > directly (the installed version, that is) if it helps.
>
> I don't really want to. I consider the test cases being entirely cut
> off from the outside internet an advantage, in most cases.
That wasn't about internet access, more about network access and a
quick way to do / draft sandboxing.
--
Stefano
next prev parent reply other threads:[~2025-08-20 12:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 11:32 [PATCH v4 0/3] RFC: New proof-of-concept based exeter tests David Gibson
2025-08-07 11:32 ` [PATCH v4 1/3] test: Extend test scripts to allow running " David Gibson
2025-08-19 14:27 ` Stefano Brivio
2025-08-20 2:55 ` David Gibson
2025-08-20 9:52 ` Stefano Brivio
2025-08-20 11:10 ` David Gibson
2025-08-20 11:44 ` Stefano Brivio
2025-08-20 23:31 ` David Gibson
2025-08-21 21:26 ` Stefano Brivio
2025-08-22 3:19 ` David Gibson
2025-08-07 11:32 ` [PATCH v4 2/3] test: Run static checkers as " David Gibson
2025-08-07 11:32 ` [PATCH v4 3/3] test: Convert build tests to exeter David Gibson
2025-08-19 14:27 ` Stefano Brivio
2025-08-20 3:10 ` David Gibson
2025-08-20 10:40 ` Stefano Brivio
2025-08-20 11:19 ` David Gibson
2025-08-20 12:13 ` Stefano Brivio [this message]
2025-08-21 0:41 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250820141301.5568a184@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).