<feed xmlns='http://www.w3.org/2005/Atom'>
<title>passt/test/distro, branch 2022_07_20.9af2e5d</title>
<subtitle>Plug A Simple Socket Transport</subtitle>
<link rel='alternate' type='text/html' href='https://passt.top/passt/'/>
<entry>
<title>tests: Remove unused DNS6 calculation from fedora tests</title>
<updated>2022-07-13T23:36:05+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:09+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=30ac86823ba0f4b80e83a6bd8ccc562f0d79b9c9'/>
<id>30ac86823ba0f4b80e83a6bd8ccc562f0d79b9c9</id>
<content type='text'>
The Fedora test file extracts some information from the host resolv.conf
into a DNS6 variable which is then never used.  Remove this unnecessary
step, which is presumably a leftover from an earlier iteration.

This was the only user of 'head' and 'sed' in the test file, so those can
also be removed from the required tools.  The debian and ubuntu test files
also listed 'head' and 'sed' as tools, although they don't use them,
I'm guessing because of an earlier version which had the same DNS6 code.
Remove those as well.

The opensuse test file still actually uses DNS6, so leave it there for now.
The DNS handling and network config handling for SuSE looks to be kind of
broken, but fixing that is a job for another day.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Fedora test file extracts some information from the host resolv.conf
into a DNS6 variable which is then never used.  Remove this unnecessary
step, which is presumably a leftover from an earlier iteration.

This was the only user of 'head' and 'sed' in the test file, so those can
also be removed from the required tools.  The debian and ubuntu test files
also listed 'head' and 'sed' as tools, although they don't use them,
I'm guessing because of an earlier version which had the same DNS6 code.
Remove those as well.

The opensuse test file still actually uses DNS6, so leave it there for now.
The DNS handling and network config handling for SuSE looks to be kind of
broken, but fixing that is a job for another day.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Prepare distro images during asset build phase</title>
<updated>2022-07-13T23:36:02+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:08+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=d2802ec874fd70b4c4dda6158f63612d6f1bffc0'/>
<id>d2802ec874fd70b4c4dda6158f63612d6f1bffc0</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Move distro image download to asset build makefile</title>
<updated>2022-07-13T23:34:37+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:07+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=32c5e054795e811420db84eb913e00ac3af8fc2b'/>
<id>32c5e054795e811420db84eb913e00ac3af8fc2b</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
[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 &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
[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 &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Search multiple places for aarch64 EDK2 bios image</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:29:01+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=b44e16ed6cc1c81e0986ec78a8fd9d1cf48bef01'/>
<id>b44e16ed6cc1c81e0986ec78a8fd9d1cf48bef01</id>
<content type='text'>
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 &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Invoke specific qemu-system-* binaries</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:28:58+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=7bcc5930a66ed8d6ba692a2463547d17390531e7'/>
<id>7bcc5930a66ed8d6ba692a2463547d17390531e7</id>
<content type='text'>
A lot of tests and examples invoke qemu with the command "kvm".  However,
as far as I can tell, "kvm" being aliased to the appropriate qemu system
binary is Debian specific.  The binary names from qemu upstream -
qemu-system-$ARCH - also aren't universal, but they are more common (they
should be good for both Debian and Fedora at least).

In order to still get KVM acceleration when available, we use the option
"-M accel=kvm:tcg" to tell qemu to try using either KVM or TCG in that
order

A number of the places we invoked "kvm" are expecting specifically an x86
guest, and so it's also safer to explicitly invoke qemu-system-x86_64.

Some others appear to be independent of the target arch (just wanting the
same arch as the host to allow KVM acceleration).  Although I suspect there
may be more subtle x86 specific options in the qemu command lines, attempt
to preserve arch independence by using $(uname -m).

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A lot of tests and examples invoke qemu with the command "kvm".  However,
as far as I can tell, "kvm" being aliased to the appropriate qemu system
binary is Debian specific.  The binary names from qemu upstream -
qemu-system-$ARCH - also aren't universal, but they are more common (they
should be good for both Debian and Fedora at least).

In order to still get KVM acceleration when available, we use the option
"-M accel=kvm:tcg" to tell qemu to try using either KVM or TCG in that
order

A number of the places we invoked "kvm" are expecting specifically an x86
guest, and so it's also safer to explicitly invoke qemu-system-x86_64.

Some others appear to be independent of the target arch (just wanting the
same arch as the host to allow KVM acceleration).  Although I suspect there
may be more subtle x86 specific options in the qemu command lines, attempt
to preserve arch independence by using $(uname -m).

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: qemu-system-ppc64le isn't a thing</title>
<updated>2022-07-13T23:32:42+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-07-06T07:28:57+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=c4d8a77512bf7e8224f3aff930ed48a680b4ea53'/>
<id>c4d8a77512bf7e8224f3aff930ed48a680b4ea53</id>
<content type='text'>
Several tests run pp64le guests using "qemu-system-ppc64le".  But, at the
system level there's no difference between ppc64 and ppc64le - it's the
same hardware, just placed into different endian modes by OS early boot
code.  Reflecting that, qemu only supplies a single "qemu-system-ppc64".

Some distros alias qemu-system-ppc64le to qemu-system-ppc64 (Debian does),
but it's best not to count on this (Fedora doesn't, for example).

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Several tests run pp64le guests using "qemu-system-ppc64le".  But, at the
system level there's no difference between ppc64 and ppc64le - it's the
same hardware, just placed into different endian modes by OS early boot
code.  Reflecting that, qemu only supplies a single "qemu-system-ppc64".

Some distros alias qemu-system-ppc64le to qemu-system-ppc64 (Debian does),
but it's best not to count on this (Fedora doesn't, for example).

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Makefile: Use $(BIN) and $(MANPAGES) variable to simplify several targets</title>
<updated>2022-06-18T07:06:00+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-06-14T05:12:22+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=25f515831cef1faf6f2e73c8a6b58a0db803786f'/>
<id>25f515831cef1faf6f2e73c8a6b58a0db803786f</id>
<content type='text'>
There are several places which explicitly list the various generated
binaries, even though a $(BIN) variable already lists them.  There are
several more places that list all the manpage files, introduce a
$(MANPAGES) variable to remove that repetition as well.

Tweak the generation of pasta.1 as a link to passt.1 so it's not just made
as a side effect of the pasta target.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: add passt.1 and qrap.1 to guest files for distro tests]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are several places which explicitly list the various generated
binaries, even though a $(BIN) variable already lists them.  There are
several more places that list all the manpage files, introduce a
$(MANPAGES) variable to remove that repetition as well.

Tweak the generation of pasta.1 as a link to passt.1 so it's not just made
as a side effect of the pasta target.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: add passt.1 and qrap.1 to guest files for distro tests]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Tweak dhclient arguments for readability</title>
<updated>2022-06-15T07:38:10+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-06-10T02:32:43+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=ca0c33ae5b8a68806dd1c766e2f58ce24867f334'/>
<id>ca0c33ae5b8a68806dd1c766e2f58ce24867f334</id>
<content type='text'>
A number of tests and examples use dhclient in both IPv4 and IPv6 modes.
We use "dhclient -6" for IPv6, but usually just "dhclient" for IPv4.  Add
an explicit "-4" argument to make it more clear and explicit.

In addition, when dhclient is run from within pasta it usually won't be
"real" root, and so will not have access to write the default global pid
file.  This results in a mostly harmless but irritating error:
    Can't create /var/run/dhclient.pid: Permission denied
We can avoid that by using the --no-pid flag to dhclient.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A number of tests and examples use dhclient in both IPv4 and IPv6 modes.
We use "dhclient -6" for IPv6, but usually just "dhclient" for IPv4.  Add
an explicit "-4" argument to make it more clear and explicit.

In addition, when dhclient is run from within pasta it usually won't be
"real" root, and so will not have access to write the default global pid
file.  This results in a mostly harmless but irritating error:
    Can't create /var/run/dhclient.pid: Permission denied
We can avoid that by using the --no-pid flag to dhclient.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Use more explicit netcat options for distro/fedora tests</title>
<updated>2022-06-15T07:37:03+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-06-10T02:32:41+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=6703da44c16b9bdfc4d959db270961d8ab826570'/>
<id>6703da44c16b9bdfc4d959db270961d8ab826570</id>
<content type='text'>
distro/fedora contains two versions of the basic tests, used for different
Fedora versions.  One uses explicit listening address for netcat in some
extra places, the other does not.  Apparently the older netcat versions
didn't require the explicit addresses.  Not supplying addresses doesn't
test anything useful though, just a detail in netcat's behaviour.  So,
it's cleaner to just always supply explicit addresses.

In addition, we're explicitly expecting the nmap version of ncat, also
known as "ncat".  So, it's more explicit what we're after if we invoke it
via that name rather than "nc", which will go via an /etc/alternatives
link.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: Fix port argument in distro_quick_pasta_test{,_fedora34} too]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
distro/fedora contains two versions of the basic tests, used for different
Fedora versions.  One uses explicit listening address for netcat in some
extra places, the other does not.  Apparently the older netcat versions
didn't require the explicit addresses.  Not supplying addresses doesn't
test anything useful though, just a detail in netcat's behaviour.  So,
it's cleaner to just always supply explicit addresses.

In addition, we're explicitly expecting the nmap version of ncat, also
known as "ncat".  So, it's more explicit what we're after if we invoke it
via that name rather than "nc", which will go via an /etc/alternatives
link.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: Fix port argument in distro_quick_pasta_test{,_fedora34} too]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tests: Simplify explicit checks for command success</title>
<updated>2022-05-19T13:24:15+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2022-05-12T06:43:33+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=21e9cf7b95434c74ed7cbcead4a9e5b19e168f6e'/>
<id>21e9cf7b95434c74ed7cbcead4a9e5b19e168f6e</id>
<content type='text'>
A number of individual test cases use '*out' commands to check for success
of specific commands they've issued.  Now that the test harness is testing
for success of all issued commands as a matter of course, we no longer need
to do this.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A number of individual test cases use '*out' commands to check for success
of specific commands they've issued.  Now that the test harness is testing
for success of all issued commands as a matter of course, we no longer need
to do this.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
</pre>
</div>
</content>
</entry>
</feed>
