2017-01-18 07:15:44 +00:00
|
|
|
package tapnet;
|
|
|
|
|
|
|
|
use strict;
|
|
|
|
|
|
|
|
use base 'Exporter';
|
|
|
|
use Exporter;
|
|
|
|
|
|
|
|
use testapi;
|
|
|
|
our @EXPORT = qw/clone_host_file setup_tap_static get_host_dns/;
|
|
|
|
|
|
|
|
sub clone_host_file {
|
|
|
|
# copy a given file from the host into the guest. Mainly used
|
|
|
|
# for networking config on tap tests. this is pretty crazy, but
|
|
|
|
# SUSE do almost the same thing...
|
|
|
|
my $file = shift;
|
|
|
|
my $text = '';
|
|
|
|
open(my $fh, '<', $file);
|
|
|
|
while (<$fh>) {
|
|
|
|
$text .= $_;
|
|
|
|
}
|
|
|
|
# escape any " characters in the text...
|
|
|
|
$text =~ s/"/\\"/g;
|
|
|
|
assert_script_run "printf \"$text\" > $file";
|
|
|
|
# for debugging...
|
|
|
|
assert_script_run "cat $file";
|
|
|
|
}
|
|
|
|
|
|
|
|
sub setup_tap_static {
|
|
|
|
# this is a common thing for tap tests, where we set up networking
|
|
|
|
# for the system with a static IP address and possibly a specific
|
|
|
|
# hostname
|
|
|
|
my $ip = shift;
|
|
|
|
my $hostname = shift || "";
|
|
|
|
if ($hostname) {
|
|
|
|
# assigning output of split to a single-item array gives us just
|
|
|
|
# the first split
|
|
|
|
my ($short) = split(/\./, $hostname);
|
|
|
|
# set hostname
|
|
|
|
assert_script_run "hostnamectl set-hostname $hostname";
|
|
|
|
# add entry to /etc/hosts
|
|
|
|
assert_script_run "echo '$ip $hostname $short' >> /etc/hosts";
|
|
|
|
}
|
Add support for testing updates
Summary:
This adds an entirely new workflow for testing distribution
updates. The `ADVISORY` variable is introduced: when set,
`main.pm` will load an early post-install test that sets up
a repository containing the packages from the specified update,
runs `dnf -y update`, and reboots. A new templates file is
added, `templates-updates`, which adds two new flavors called
`updates-server` and `updates-workstation`, each containing
job templates for appropriate post-install tests. Scheduler is
expected to post `ADVISORY=(update ID) HDD_1=(base image)
FLAVOR=updates-(server|workstation)`, where (base image) is one
of the stable release base disk images produced by `createhdds`
and usually used for upgrade testing. This will result in the
appropriate job templates being loaded.
We rejig postinstall test loading and static network config a
bit so that this works for both the 'compose' and 'updates' test
flows: we have to ensure we bring up networking for the tap
tests before we try and install the updates, but still allow
later adjustment of the configuration. We take advantage of the
openQA feature that was added a few months back to run the same
module multiple times, so the `_advisory_update` module can
reboot after installing the updates and the modules that take
care of bootloader, encryption and login get run again. This
looks slightly wacky in the web UI, though - it doesn't show the
later runs of each module.
We also use the recently added feature to specify `+HDD_1` in
the test suites which use a disk image uploaded by an earlier
post-install test, so the test suite value will take priority
over the value POSTed by the scheduler for those tests, and we
will use the uploaded disk image (and not the clean base image
POSTed by the scheduler) for those tests.
My intent here is to enhance the scheduler, adding a consumer
which listens out for critpath updates, and runs this test flow
for each one, then reports the results to ResultsDB where Bodhi
could query and display them. We could also add a list of other
packages to have one or both sets of update tests run on it, I
guess.
Test Plan:
Try a post something like:
HDD_1=disk_f25_server_3_x86_64.img DISTRI=fedora VERSION=25
FLAVOR=updates-server ARCH=x86_64 BUILD=FEDORA-2017-376ae2b92c
ADVISORY=FEDORA-2017-376ae2b92c CURRREL=25 PREVREL=24
Pick an appropriate `ADVISORY` (ideally, one containing some
packages which might actually be involved in the tests), and
matching `FLAVOR` and `HDD_1`. The appropriate tests should run,
a repo with the update packages should be created and enabled
(and dnf update run), and the tests should work properly. Also
test a regular compose run to make sure I didn't break anything.
Reviewers: jskladan, jsedlak
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1143
2017-01-25 16:16:12 +00:00
|
|
|
# use host's name servers (this is usually going to be correct,
|
|
|
|
# tests which don't want this can overwrite resolv.conf)
|
|
|
|
my @dns = get_host_dns();
|
2020-08-21 22:56:44 +00:00
|
|
|
my $dnstext = 'ipv4.dns "' . join(", ", @dns) . '"';
|
|
|
|
# bring up network
|
|
|
|
# this gets us the name of the first connection in the list,
|
|
|
|
# which should be what we want
|
|
|
|
my $connection = script_output "nmcli --fields NAME con show | head -2 | tail -1";
|
|
|
|
assert_script_run "nmcli con mod '$connection' ipv4.method manual ipv4.addr $ip/24 ipv4.gateway 172.16.2.2 $dnstext";
|
|
|
|
assert_script_run "nmcli con down '$connection'";
|
|
|
|
assert_script_run "nmcli con up '$connection'";
|
|
|
|
# for debugging
|
|
|
|
assert_script_run "nmcli -t con show '$connection'";
|
Add support for testing updates
Summary:
This adds an entirely new workflow for testing distribution
updates. The `ADVISORY` variable is introduced: when set,
`main.pm` will load an early post-install test that sets up
a repository containing the packages from the specified update,
runs `dnf -y update`, and reboots. A new templates file is
added, `templates-updates`, which adds two new flavors called
`updates-server` and `updates-workstation`, each containing
job templates for appropriate post-install tests. Scheduler is
expected to post `ADVISORY=(update ID) HDD_1=(base image)
FLAVOR=updates-(server|workstation)`, where (base image) is one
of the stable release base disk images produced by `createhdds`
and usually used for upgrade testing. This will result in the
appropriate job templates being loaded.
We rejig postinstall test loading and static network config a
bit so that this works for both the 'compose' and 'updates' test
flows: we have to ensure we bring up networking for the tap
tests before we try and install the updates, but still allow
later adjustment of the configuration. We take advantage of the
openQA feature that was added a few months back to run the same
module multiple times, so the `_advisory_update` module can
reboot after installing the updates and the modules that take
care of bootloader, encryption and login get run again. This
looks slightly wacky in the web UI, though - it doesn't show the
later runs of each module.
We also use the recently added feature to specify `+HDD_1` in
the test suites which use a disk image uploaded by an earlier
post-install test, so the test suite value will take priority
over the value POSTed by the scheduler for those tests, and we
will use the uploaded disk image (and not the clean base image
POSTed by the scheduler) for those tests.
My intent here is to enhance the scheduler, adding a consumer
which listens out for critpath updates, and runs this test flow
for each one, then reports the results to ResultsDB where Bodhi
could query and display them. We could also add a list of other
packages to have one or both sets of update tests run on it, I
guess.
Test Plan:
Try a post something like:
HDD_1=disk_f25_server_3_x86_64.img DISTRI=fedora VERSION=25
FLAVOR=updates-server ARCH=x86_64 BUILD=FEDORA-2017-376ae2b92c
ADVISORY=FEDORA-2017-376ae2b92c CURRREL=25 PREVREL=24
Pick an appropriate `ADVISORY` (ideally, one containing some
packages which might actually be involved in the tests), and
matching `FLAVOR` and `HDD_1`. The appropriate tests should run,
a repo with the update packages should be created and enabled
(and dnf update run), and the tests should work properly. Also
test a regular compose run to make sure I didn't break anything.
Reviewers: jskladan, jsedlak
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1143
2017-01-25 16:16:12 +00:00
|
|
|
# the above doesn't seem to reliably set up resolv.conf, so...
|
|
|
|
clone_host_file "/etc/resolv.conf";
|
2017-01-18 07:15:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
sub get_host_dns {
|
|
|
|
# get DNS server addresses from the host
|
|
|
|
my @forwards;
|
|
|
|
open(FH, '<', "/etc/resolv.conf");
|
|
|
|
while (<FH>) {
|
|
|
|
if ($_ =~ m/^nameserver +(.+)/) {
|
|
|
|
push @forwards, $1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return @forwards;
|
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|