mirrors/passt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
passt/test/Makefile

210 lines
7.5 KiB
Makefile
Raw Normal View History

passt: Relicense to GPL 2.0, or any later version In practical terms, passt doesn't benefit from the additional protection offered by the AGPL over the GPL, because it's not suitable to be executed over a computer network. Further, restricting the distribution under the version 3 of the GPL wouldn't provide any practical advantage either, as long as the passt codebase is concerned, and might cause unnecessary compatibility dilemmas. Change licensing terms to the GNU General Public License Version 2, or any later version, with written permission from all current and past contributors, namely: myself, David Gibson, Laine Stump, Andrea Bolognani, Paul Holzinger, Richard W.M. Jones, Chris Kuhn, Florian Weimer, Giuseppe Scrivano, Stefan Hajnoczi, and Vasiliy Ulyanov. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-05 20:11:44 +02:00
# SPDX-License-Identifier: GPL-2.0-or-later
tests: Introduce makefile for building test assets A number of passt/pasta testcases have initial steps which are just about building images or other assets we need for the test proper. Repeating these for each test run can be quite costly. This patch makes a start on moving this sort of test asset building to a separate phase before running the tests proper. For now just add a Makefile to handle the asset building (although it doesn't build anything yet), and make the path where we'll be building the assets available to the tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:28:59 +02:00
#
# Tests makefile
#
# Copyright Red Hat
# Author: David Gibson <david@gibson.dropbear.id.au>
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
WGET = wget -c
DEBIAN_IMGS = debian-8.11.0-openstack-amd64.qcow2 \
debian-10-nocloud-amd64.qcow2 \
debian-10-generic-arm64.qcow2 \
test: Update location for Debian ppc64 images The current debian cloud images no longer include ppc64. Change to using the latest snapshot which does include ppc64. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-02-14 00:37:12 +01:00
debian-10-generic-ppc64el-20220911-1135.qcow2 \
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
debian-11-nocloud-amd64.qcow2 \
debian-11-generic-arm64.qcow2 \
debian-11-generic-ppc64el.qcow2 \
debian-sid-nocloud-amd64-daily.qcow2 \
debian-sid-nocloud-arm64-daily.qcow2 \
debian-sid-nocloud-ppc64el-daily.qcow2
FEDORA_IMGS = Fedora-Cloud-Base-26-1.5.x86_64.qcow2 \
Fedora-Cloud-Base-27-1.6.x86_64.qcow2 \
Fedora-Cloud-Base-28-1.1.x86_64.qcow2 \
Fedora-Cloud-Base-28-1.1.aarch64.qcow2 \
Fedora-Cloud-Base-29-1.2.x86_64.qcow2 \
Fedora-Cloud-Base-29-1.2.aarch64.qcow2 \
Fedora-Cloud-Base-30-1.2.x86_64.qcow2 \
Fedora-Cloud-Base-30-1.2.aarch64.qcow2 \
Fedora-Cloud-Base-31-1.9.x86_64.qcow2 \
Fedora-Cloud-Base-31-1.9.aarch64.qcow2 \
Fedora-Cloud-Base-32-1.6.x86_64.qcow2 \
Fedora-Cloud-Base-32-1.6.aarch64.qcow2 \
Fedora-Cloud-Base-33-1.2.x86_64.qcow2 \
Fedora-Cloud-Base-33-1.2.aarch64.qcow2 \
Fedora-Cloud-Base-34-1.2.x86_64.qcow2 \
Fedora-Cloud-Base-34-1.2.aarch64.qcow2 \
Fedora-Cloud-Base-35-1.2.x86_64.qcow2 \
Fedora-Cloud-Base-35-1.2.aarch64.qcow2
OPENSUSE_IMGS = openSUSE-Leap-15.1-JeOS.x86_64-kvm-and-xen.qcow2 \
openSUSE-Leap-15.2-JeOS.x86_64-kvm-and-xen.qcow2 \
openSUSE-Leap-15.3-JeOS.x86_64-kvm-and-xen.qcow2 \
openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64.raw.xz \
test: remove obsolete images Remove debian-9-nocloud-amd64-daily-20200210-166.qcow2 and openSUSE-Tumbleweed-JeOS.x86_64-kvm-and-xen.qcow2 as they cannot be downloaded anymore Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-10-25 09:49:10 +02:00
openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l.raw.xz
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
tests: Prepare distro images during asset build phase Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:08 +02:00
UBUNTU_OLD_IMGS = trusty-server-cloudimg-amd64-disk1.img \
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
trusty-server-cloudimg-i386-disk1.img \
tests: Prepare distro images during asset build phase Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:08 +02:00
trusty-server-cloudimg-ppc64el-disk1.img
UBUNTU_NEW_IMGS = xenial-server-cloudimg-powerpc-disk1.img \
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
jammy-server-cloudimg-s390x.img
tests: Prepare distro images during asset build phase Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:08 +02:00
UBUNTU_IMGS = $(UBUNTU_OLD_IMGS) $(UBUNTU_NEW_IMGS)
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
test: Build and download podman as a test asset The pasta_podman/bats test scrpt downloads and builds podman, then runs its pasta specific tests. Downloading from within a test case has some drawbacks: * It can be very tedious if you have poor connectivity to the server * It makes a test that's ostensibly for pasta itself dependent on the state of the github server * It precludes runnning the tests in an isolated network environment The same concerns largely apply to building podman too, because it's pretty common for Go builds to download dependencies themselves. Therefore move the download and build of podman from the test itself, to the Makefile where we prepare other test assets. To avoid cryptic failures if something went wrong with the build, make running the test dependent on having the built podman binary. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-21 05:57:40 +01:00
DOWNLOAD_ASSETS = mbuto podman \
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
$(DEBIAN_IMGS) $(FEDORA_IMGS) $(OPENSUSE_IMGS) $(UBUNTU_IMGS)
test: Simplify data handling for transfer tests Many of our tests are based around performing transfers of sample data across passt/pasta created links. The data flow here can be a bit hard to follow since, e.g. we create a file transfer it to the guest, then transfer it back to the host across several different tests. This also means that the test cases aren't independent of each other. Because we don't have the original file available at both ends in some cases, we compare them by generating md5sums at each end and comparing them, which is a bit complicated. Make a number of changes to simplify this: 1. Pre-generate the sample data files as a test asset, rather than building them on the fly during the tests proper 2. Include the sample data files in the mbuto guest image 3. Because we have good copies of the original data available in all contexts, we can now simply use 'cmp' to check if the transfer has worked, avoiding md5sum complications. 4. Similarly we can always use the original copy of the sample data on the send side of each transfer, meaning that the tests become more independent of each other. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-26 12:43:40 +02:00
TESTDATA_ASSETS = small.bin big.bin medium.bin
test: Build and download podman as a test asset The pasta_podman/bats test scrpt downloads and builds podman, then runs its pasta specific tests. Downloading from within a test case has some drawbacks: * It can be very tedious if you have poor connectivity to the server * It makes a test that's ostensibly for pasta itself dependent on the state of the github server * It precludes runnning the tests in an isolated network environment The same concerns largely apply to building podman too, because it's pretty common for Go builds to download dependencies themselves. Therefore move the download and build of podman from the test itself, to the Makefile where we prepare other test assets. To avoid cryptic failures if something went wrong with the build, make running the test dependent on having the built podman binary. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-21 05:57:40 +01:00
LOCAL_ASSETS = mbuto.img mbuto.mem.img podman/bin/podman QEMU_EFI.fd \
tests: Prepare distro images during asset build phase Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:08 +02:00
$(DEBIAN_IMGS:%=prepared-%) $(FEDORA_IMGS:%=prepared-%) \
test: Add nsholder utility In our test scripts we need to do some ugly parsing of /proc and/or pstree output in order to get the PIDs of processes running in namespaces so that we can connect to those namespaces with nsenter or pasta. This is actually a pretty tricky problem with standard tools. To determine the PID from the outside of the namespace we need to know how the process of interest is related to the unshare or pasta process (child? one of several children? grandchild?) as well as then parsing /proc or ps output. This is slightly awkward now, and will get worse with future changes I'd like to make to have processes are dispatched. The obvious solution would be to have the process of interest (which we control) report its own PID, but that doesn't work easily, because it is in a PID namepace and sees only its local PID not the global PID we need to address it from outside. To handle this, add a small custom tool, "nsholder". This takes a path and a mode parameter. In "hold" mode it will create a unix domain socket bound to the path and listening. In "pid" mode it will get the "hold"ing process's pid via the unix socket using SO_PEERCRED, which translates between PID namespaces. In "stop" mode it will send a message to the socket causing the "hold"ing process to clean up and exit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-12 12:56:20 +02:00
$(UBUNTU_NEW_IMGS:%=prepared-%) \
nstool: Rename nsholder to nstool In preparation for extending what it does. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-06 05:28:06 +02:00
nstool guest-key guest-key.pub \
test: Simplify data handling for transfer tests Many of our tests are based around performing transfers of sample data across passt/pasta created links. The data flow here can be a bit hard to follow since, e.g. we create a file transfer it to the guest, then transfer it back to the host across several different tests. This also means that the test cases aren't independent of each other. Because we don't have the original file available at both ends in some cases, we compare them by generating md5sums at each end and comparing them, which is a bit complicated. Make a number of changes to simplify this: 1. Pre-generate the sample data files as a test asset, rather than building them on the fly during the tests proper 2. Include the sample data files in the mbuto guest image 3. Because we have good copies of the original data available in all contexts, we can now simply use 'cmp' to check if the transfer has worked, avoiding md5sum complications. 4. Similarly we can always use the original copy of the sample data on the send side of each transfer, meaning that the tests become more independent of each other. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-26 12:43:40 +02:00
$(TESTDATA_ASSETS)
tests: Introduce makefile for building test assets A number of passt/pasta testcases have initial steps which are just about building images or other assets we need for the test proper. Repeating these for each test run can be quite costly. This patch makes a start on moving this sort of test asset building to a separate phase before running the tests proper. For now just add a Makefile to handle the asset building (although it doesn't build anything yet), and make the path where we'll be building the assets available to the tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:28:59 +02:00
ASSETS = $(DOWNLOAD_ASSETS) $(LOCAL_ASSETS)
Stricter checking for nsholder.c Add the -Wextra -pedantic and -std=c99 flags when compiling the nsholder test helper to get extra compiler checks, like we already use for the main source code. While we're there, fix some %d (signed) printf descriptors being used for unsigned values (uid_t and gid_t). Pointed out by cppcheck. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-28 06:33:22 +02:00
CFLAGS = -Wall -Werror -Wextra -pedantic -std=c99
test: Add nsholder utility In our test scripts we need to do some ugly parsing of /proc and/or pstree output in order to get the PIDs of processes running in namespaces so that we can connect to those namespaces with nsenter or pasta. This is actually a pretty tricky problem with standard tools. To determine the PID from the outside of the namespace we need to know how the process of interest is related to the unshare or pasta process (child? one of several children? grandchild?) as well as then parsing /proc or ps output. This is slightly awkward now, and will get worse with future changes I'd like to make to have processes are dispatched. The obvious solution would be to have the process of interest (which we control) report its own PID, but that doesn't work easily, because it is in a PID namepace and sees only its local PID not the global PID we need to address it from outside. To handle this, add a small custom tool, "nsholder". This takes a path and a mode parameter. In "hold" mode it will create a unix domain socket bound to the path and listening. In "pid" mode it will get the "hold"ing process's pid via the unix socket using SO_PEERCRED, which translates between PID namespaces. In "stop" mode it will send a message to the socket causing the "hold"ing process to clean up and exit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-12 12:56:20 +02:00
tests: Introduce makefile for building test assets A number of passt/pasta testcases have initial steps which are just about building images or other assets we need for the test proper. Repeating these for each test run can be quite costly. This patch makes a start on moving this sort of test asset building to a separate phase before running the tests proper. For now just add a Makefile to handle the asset building (although it doesn't build anything yet), and make the path where we'll be building the assets available to the tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:28:59 +02:00
assets: $(ASSETS)
test: Make sure to update mbuto repository We download and use mbuto to build trivial boot images for our VM tests. However, if mbuto is already cloned, we won't update it to the current version. Add some make logic to ensure that we do this. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-21 05:57:39 +01:00
.PHONY: pull-%
pull-%: %
git -C $* pull
tests: Move mbuto download and execution to asset build Move the download of mbuto and using it to create a sample initramfs to the asset build makefile, rather than embedding it in the test scripts themselves. The two_guests tests used to use two separate copies of the mbuto image. As an initramfs the mbuto image is strictly readonly though, so that's not necessary. So, also use the same image for both guests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:00 +02:00
mbuto:
git clone git://mbuto.sh/mbuto
test: Make sure to update mbuto repository We download and use mbuto to build trivial boot images for our VM tests. However, if mbuto is already cloned, we won't update it to the current version. Add some make logic to ensure that we do this. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-21 05:57:39 +01:00
mbuto/mbuto: pull-mbuto
test: Build and download podman as a test asset The pasta_podman/bats test scrpt downloads and builds podman, then runs its pasta specific tests. Downloading from within a test case has some drawbacks: * It can be very tedious if you have poor connectivity to the server * It makes a test that's ostensibly for pasta itself dependent on the state of the github server * It precludes runnning the tests in an isolated network environment The same concerns largely apply to building podman too, because it's pretty common for Go builds to download dependencies themselves. Therefore move the download and build of podman from the test itself, to the Makefile where we prepare other test assets. To avoid cryptic failures if something went wrong with the build, make running the test dependent on having the built podman binary. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-21 05:57:40 +01:00
podman:
git clone https://github.com/containers/podman.git
# To succesfully build podman, you will need gpgme and systemd
# development packages
podman/bin/podman: pull-podman
$(MAKE) -C podman
test: Use context system for guest commands Extends the context system in the test scripts to allow executing commands within a guest. Do this without requiring an existing network in the guest by using socat to run ssh via a vsock connection. We do need some additional "sleep"s in the tests, because the new faster dispatch means that sometimes we attempt to connect before socat has managed to listen. For now, only use this for the plain "passt" tests. The "passt_in_ns" and other tests have additional complications we still need to deal with. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-12 12:56:22 +02:00
guest-key guest-key.pub:
ssh-keygen -f guest-key -N ''
test: Make sure to update mbuto repository We download and use mbuto to build trivial boot images for our VM tests. However, if mbuto is already cloned, we won't update it to the current version. Add some make logic to ensure that we do this. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2024-03-21 05:57:39 +01:00
mbuto.img: passt.mbuto mbuto/mbuto guest-key.pub $(TESTDATA_ASSETS)
tests: Move mbuto download and execution to asset build Move the download of mbuto and using it to create a sample initramfs to the asset build makefile, rather than embedding it in the test scripts themselves. The two_guests tests used to use two separate copies of the mbuto image. As an initramfs the mbuto image is strictly readonly though, so that's not necessary. So, also use the same image for both guests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:00 +02:00
./mbuto/mbuto -p ./$< -c lz4 -f $@
test: Add memory/passt test cases These show a summary of memory usage in kernel and userspace with different port forwarding configurations, details of userspace usage using 'nm' (passt only uses statically allocated memory), and details of kernel memory from slab reporting facilities. This adds a new test image, mbuto.mem.img, with harcoded IPv4 and IPv6 addresses and routes, and just the tools we need to start and stop passt, to report from /proc/slabinfo, /proc/meminfo, and to print and parse symbol sizes using nm(1). passt can't pivot_root() for sandboxing purposes on ramfs, so we need to create another filesystem and chroot into it, first. We don't want to use pane context functions, as we're checking memory usage for sockets: resort to screen-scraping. Configure a dummy interface to provide passt with an appearance of working IPv4 and IPv6 connectivity, contributed by David. Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
2022-10-31 12:20:59 +01:00
mbuto.mem.img: passt.mem.mbuto mbuto ../passt.avx2
./mbuto/mbuto -p ./$< -c lz4 -f $@
nstool: Rename nsholder to nstool In preparation for extending what it does. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-04-06 05:28:06 +02:00
nstool: nstool.c
test: Add nsholder utility In our test scripts we need to do some ugly parsing of /proc and/or pstree output in order to get the PIDs of processes running in namespaces so that we can connect to those namespaces with nsenter or pasta. This is actually a pretty tricky problem with standard tools. To determine the PID from the outside of the namespace we need to know how the process of interest is related to the unshare or pasta process (child? one of several children? grandchild?) as well as then parsing /proc or ps output. This is slightly awkward now, and will get worse with future changes I'd like to make to have processes are dispatched. The obvious solution would be to have the process of interest (which we control) report its own PID, but that doesn't work easily, because it is in a PID namepace and sees only its local PID not the global PID we need to address it from outside. To handle this, add a small custom tool, "nsholder". This takes a path and a mode parameter. In "hold" mode it will create a unix domain socket bound to the path and listening. In "pid" mode it will get the "hold"ing process's pid via the unix socket using SO_PEERCRED, which translates between PID namespaces. In "stop" mode it will send a message to the socket causing the "hold"ing process to clean up and exit. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-09-12 12:56:20 +02:00
$(CC) $(CFLAGS) -o $@ $^
tests: Search multiple places for aarch64 EDK2 bios image Apparently qemu's ARM virt machine needs to be explicitly given a firmware image, rather than just supplying a sane default. Unfortunately the EDK2 firmware image we need isn't in the same place on all host distros. Currently the test scripts hardcode the Debian location, meaning it will break on hosts that have it somewhere else. This patch searches multiple locations for the firmware, and creates a local link during the asset build phase, which the tests can then use. For now it only searches the locations used by Debian and Fedora, but that's a small improvement in robustness already, and can be later improved further if we need to. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:01 +02:00
QEMU_EFI.fd:
./find-arm64-firmware.sh $@
tests: Prepare distro images during asset build phase Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:08 +02:00
prepared-%.qcow2: %.qcow2 ./prepare-distro-img.sh
qemu-img create -f qcow2 -F qcow2 -b $< $@
./prepare-distro-img.sh $@
prepared-%.img: %.img ./prepare-distro-img.sh
qemu-img create -f qcow2 -F qcow2 -b $< $@
./prepare-distro-img.sh $(IMGTYPE) $@
test: Simplify data handling for transfer tests Many of our tests are based around performing transfers of sample data across passt/pasta created links. The data flow here can be a bit hard to follow since, e.g. we create a file transfer it to the guest, then transfer it back to the host across several different tests. This also means that the test cases aren't independent of each other. Because we don't have the original file available at both ends in some cases, we compare them by generating md5sums at each end and comparing them, which is a bit complicated. Make a number of changes to simplify this: 1. Pre-generate the sample data files as a test asset, rather than building them on the fly during the tests proper 2. Include the sample data files in the mbuto guest image 3. Because we have good copies of the original data available in all contexts, we can now simply use 'cmp' to check if the transfer has worked, avoiding md5sum complications. 4. Similarly we can always use the original copy of the sample data on the send side of each transfer, meaning that the tests become more independent of each other. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-09-26 12:43:40 +02:00
small.bin:
dd if=/dev/urandom bs=2k count=1 of=$@
medium.bin:
dd if=/dev/urandom bs=1k count=5 of=$@
big.bin:
dd if=/dev/urandom bs=1M count=10 of=$@
tests: Introduce makefile for building test assets A number of passt/pasta testcases have initial steps which are just about building images or other assets we need for the test proper. Repeating these for each test run can be quite costly. This patch makes a start on moving this sort of test asset building to a separate phase before running the tests proper. For now just add a Makefile to handle the asset building (although it doesn't build anything yet), and make the path where we'll be building the assets available to the tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:28:59 +02:00
check: assets
./run
debug: assets
DEBUG=1 ./run
clean:
rm -f perf.js *~
rm -f $(LOCAL_ASSETS)
rm -rf test_logs
tests: Prepare distro images during asset build phase Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:29:08 +02:00
rm -f prepared-*.qcow2 prepared-*.img
tests: Introduce makefile for building test assets A number of passt/pasta testcases have initial steps which are just about building images or other assets we need for the test proper. Repeating these for each test run can be quite costly. This patch makes a start on moving this sort of test asset building to a separate phase before running the tests proper. For now just add a Makefile to handle the asset building (although it doesn't build anything yet), and make the path where we'll be building the assets available to the tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-07-06 09:28:59 +02:00
realclean: clean
rm -rf $(DOWNLOAD_ASSETS)
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
# Debian downloads
debian-8.11.0-openstack-%.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/OpenStack/archive/8.11.0/debian-8.11.0-openstack-$*.qcow2
debian-10-nocloud-%.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/buster/latest/debian-10-nocloud-$*.qcow2
test: Update location for Debian ppc64 images The current debian cloud images no longer include ppc64. Change to using the latest snapshot which does include ppc64. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-02-14 00:37:12 +01:00
debian-10-generic-ppc64el-20220911-1135.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/buster/20220911-1135/debian-10-generic-ppc64el-20220911-1135.qcow2
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
debian-10-generic-%.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/buster/latest/debian-10-generic-$*.qcow2
debian-11-nocloud-%.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-nocloud-$*.qcow2
debian-11-generic-%.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-generic-$*.qcow2
debian-sid-nocloud-%-daily.qcow2:
$(WGET) -O $@ https://cloud.debian.org/images/cloud/sid/daily/latest/debian-sid-nocloud-$*-daily.qcow2
# Fedora downloads
Fedora-Cloud-Base-26-1.5.%.qcow2:
$(WGET) -O $@ http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/26/CloudImages/$*/images/Fedora-Cloud-Base-26-1.5.$*.qcow2
Fedora-Cloud-Base-27-1.6.%.qcow2:
$(WGET) -O $@ http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/27/CloudImages/$*/images/Fedora-Cloud-Base-27-1.6.$*.qcow2
Fedora-Cloud-Base-28-1.1.%.qcow2:
$(WGET) -O $@ http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/28/Cloud/$*/images/Fedora-Cloud-Base-28-1.1.$*.qcow2
Fedora-Cloud-Base-29-1.2.%.qcow2:
$(WGET) -O $@ http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Cloud/$*/images/Fedora-Cloud-Base-29-1.2.$*.qcow2
Fedora-Cloud-Base-30-1.2.%.qcow2:
$(WGET) -O $@ http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/30/Cloud/$*/images/Fedora-Cloud-Base-30-1.2.$*.qcow2
Fedora-Cloud-Base-31-1.9.%.qcow2:
$(WGET) -O $@ http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/31/Cloud/$*/images/Fedora-Cloud-Base-31-1.9.$*.qcow2
Fedora-Cloud-Base-32-1.6.%.qcow2:
test: Fedora 32-35 have moved to the archives Fedora 32-35 are now old enough that they're not on all mirrors. Fetch them from the archive server instead. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-02-14 00:37:13 +01:00
$(WGET) -O $@ https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/32/Cloud/$*/images/Fedora-Cloud-Base-32-1.6.$*.qcow2
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
Fedora-Cloud-Base-33-1.2.%.qcow2:
test: Fedora 32-35 have moved to the archives Fedora 32-35 are now old enough that they're not on all mirrors. Fetch them from the archive server instead. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-02-14 00:37:13 +01:00
$(WGET) -O $@ https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/33/Cloud/$*/images/Fedora-Cloud-Base-33-1.2.$*.qcow2
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
Fedora-Cloud-Base-34-1.2.%.qcow2:
test: Fedora 32-35 have moved to the archives Fedora 32-35 are now old enough that they're not on all mirrors. Fetch them from the archive server instead. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-02-14 00:37:13 +01:00
$(WGET) -O $@ https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/34/Cloud/$*/images/Fedora-Cloud-Base-34-1.2.$*.qcow2
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
Fedora-Cloud-Base-35-1.2.%.qcow2:
test: Fedora 32-35 have moved to the archives Fedora 32-35 are now old enough that they're not on all mirrors. Fetch them from the archive server instead. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2023-02-14 00:37:13 +01:00
$(WGET) -O $@ https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/35/Cloud/$*/images/Fedora-Cloud-Base-35-1.2.$*.qcow2
tests: Move distro image download to asset build makefile Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-07-06 09:29:07 +02:00
# OpenSuSE downloads
openSUSE-Leap-15.1-JeOS.x86_64-kvm-and-xen.qcow2:
$(WGET) -O $@ https://download.opensuse.org/distribution/leap/15.1/jeos/openSUSE-Leap-15.1-JeOS.x86_64-kvm-and-xen.qcow2
openSUSE-Leap-15.2-JeOS.x86_64-kvm-and-xen.qcow2:
$(WGET) -O $@ https://download.opensuse.org/distribution/leap/15.2/appliances/openSUSE-Leap-15.2-JeOS.x86_64-kvm-and-xen.qcow2
openSUSE-Leap-15.3-JeOS.x86_64-kvm-and-xen.qcow2:
$(WGET) -O $@ https://download.opensuse.org/distribution/leap/15.3/appliances/openSUSE-Leap-15.3-JeOS.x86_64-kvm-and-xen.qcow2
openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64.raw.xz:
$(WGET) -O $@ http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64.raw.xz
openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l.raw.xz:
$(WGET) -O $@ http://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l.raw.xz
# Ubuntu downloads
trusty-server-cloudimg-%-disk1.img:
$(WGET) -O $@ https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-$*-disk1.img
xenial-server-cloudimg-powerpc-disk1.img:
$(WGET) -O $@ https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-powerpc-disk1.img
jammy-server-cloudimg-s390x.img:
$(WGET) -O $@ https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-s390x.img
Reference in a new issue Copy permalink