2015-08-05 06:23:59 +00:00
|
|
|
use base "installedtest";
|
2015-05-13 11:00:46 +00:00
|
|
|
use strict;
|
|
|
|
|
use testapi;
|
2017-01-18 07:15:44 +00:00
|
|
|
use utils;
|
2015-05-13 11:00:46 +00:00
|
|
|
|
|
|
|
|
sub run {
|
2016-01-28 05:40:07 +00:00
|
|
|
my $self = shift;
|
2016-08-12 17:08:46 +00:00
|
|
|
my $release = lc(get_var("VERSION"));
|
2018-01-05 02:34:20 +00:00
|
|
|
my $relnum = $release;
|
|
|
|
|
if ($release eq "rawhide") {
|
|
|
|
|
$relnum = get_var("RAWREL", "rawhide");
|
|
|
|
|
}
|
2015-10-27 01:02:22 +00:00
|
|
|
# disable screen blanking (download can take a long time)
|
2015-11-04 13:38:36 +00:00
|
|
|
script_run "setterm -blank 0";
|
2015-10-27 01:02:22 +00:00
|
|
|
|
Use mirrorlist instead of baseurl for updates tests
The reason we have all this horrible code to use the commented-
out baseurl lines in the repo files instead of the metalinks
that are usually used is a timing issue with the metalink
system. As a protection against stale mirrors, the metalink
system sends the package manager a list of mirrors *and a list
of recent checksums for the repo metadata*. The package manager
goes out and gets the metadata from the first mirror on the
list, then checksums it; if the checksum isn't on the list of
checksums it got from mirrormanager, it assumes that means the
mirror is stale, and tries the next on the list instead.
The problem is that MM's list of checksums is currently only
updated once an hour (by a cron job). So we kept running into
a problem where, when a test ran just after one of the repos
had been regenerated, the infra mirror it's supposed to use
would be rejected because the checksum wasn't on the list - but
not because the mirror was stale, but because it was too fresh,
it had got the new packages and metadata but mirrormanager's
list of checksums hadn't been updated to include the checksum
for the latest metadata.
All this baseurl munging code was getting ridiculous, though,
what with the tests getting more complicated and errors showing
up in the actual repo files and stuff. It occurred to me that
instead of using the baseurl we can just use the 'mirrorlist'
system instead of 'metalink'. mirrorlist is the dumber, older
system which just provides the package manager a list of mirrors
and nothing else - the whole stale-mirror-detection-checksum
thing does not happen with mirrorlists, the package manager just
tries all the mirrors in order and uses the first that works.
And happily, it's very easy to convert the metalink URLs into
mirrorlist URLs, and it saves all that faffing around trying to
fix up baseurls.
Also, adjust upgrade_boot to do the s/metalink/mirrorlist/
substitution, so upgrade tests don't run into the timing issue
in the steps before the main repo_setup run is done by
upgrade_run, and adjust repo_setup_compose to sub this line out
later.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-05-09 19:35:59 +00:00
|
|
|
# use compose repo (compose tests) or set up update repo (update tests)
|
2020-03-06 22:00:00 +00:00
|
|
|
cleanup_workaround_repo;
|
2017-01-18 07:15:44 +00:00
|
|
|
repo_setup();
|
2018-01-05 02:34:20 +00:00
|
|
|
my $params = "-y --releasever=${relnum}";
|
use compose repository (not master repo) for most tests
Summary:
we have a long-standing problem with all the tests that hit
the repositories. The tests are triggered as soon as a compose
completes. At this point in time, the compose is not synced to
the mirrors, where the default 'fedora' repo definition looks;
the sync happens after the compose completes, and there is also
a metadata sync step that must happen after *that* before any
operation that uses the 'fedora' repository definition will
actually use the packages from the new compose. Thus all net
install tests and tests that installed packages have been
effectively testing the previous compose, not the current one.
We have some thoughts about how to fix this 'properly' (such
that the openQA tests wouldn't have to do anything special,
but their 'fedora' repository would somehow reflect the compose
under test), but none of them is in place right now or likely
to happen in the short term, so in the mean time this should
deal with most of the issues. With this change, everything but
the default_install tests for the netinst images should use
the compose-under-test's Everything tree instead of the 'fedora'
repository, and thus should install and test the correct
packages.
This relies on a corresponding change to openqa_fedora_tools
to set the LOCATION openQA setting (which is simply the base
location of the compose under test).
Test Plan:
Do a full test run, check (as far as you can) tests run sensibly
and use appropriate repositories.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D989
2016-09-01 15:22:59 +00:00
|
|
|
if ($release eq "rawhide") {
|
|
|
|
|
$params .= " --nogpgcheck";
|
|
|
|
|
}
|
2017-02-15 14:20:35 +00:00
|
|
|
|
|
|
|
|
if (script_run "dnf ${params} system-upgrade download", 6000) {
|
|
|
|
|
record_soft_failure "dnf failed so retry with --allowerasing";
|
|
|
|
|
$params .= " --allowerasing";
|
|
|
|
|
assert_script_run "dnf ${params} system-upgrade download", 6000;
|
|
|
|
|
}
|
2015-05-13 11:00:46 +00:00
|
|
|
|
convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:
1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).
2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.
3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.
Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 21:49:13 +00:00
|
|
|
upload_logs "/var/log/dnf.log";
|
|
|
|
|
upload_logs "/var/log/dnf.rpm.log";
|
2015-05-13 11:00:46 +00:00
|
|
|
|
2016-10-22 00:42:28 +00:00
|
|
|
script_run "dnf system-upgrade reboot", 0;
|
Test upgrade of FreeIPA server and client deployment
Summary:
This adds an upgrade variant of the FreeIPA tests, with only
the simplest client enrolment (sssd) for now. The server test
starts from the N-1 release and deploys the domain controller
role. The client test similarly starts from the N-1 release
and, when the server is deployed, enrols as a domain client.
Then the server upgrades itself, while the client waits (as the
server is its name server). Then the client upgrades itself,
while the server does some self-checks. The server then waits
for the client to do its checks before decommissioning itself,
as usual. So, summary: *deployment* of both server and client
occurs on N-1, then both are upgraded, then the actual *checks*
occur on N.
In my testing, this all more or less works, except the role
decommission step fails. This failure seems to be a genuine one
so far as I can tell; I intend to file a bug for it soon.
Test Plan:
Run the new tests, check they work. Run the existing
FreeIPA tests (both the compose and the update variants), check
they both behave the same.
Reviewers: jsedlak, jskladan
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1204
2017-05-17 19:39:45 +00:00
|
|
|
# fail immediately if we see a DNF error message, but keep an eye
|
|
|
|
|
# out for the bootloader so we can handle it if requested
|
|
|
|
|
check_screen ["upgrade_fail", "bootloader"], 15;
|
|
|
|
|
die "DNF reported failure" if (match_has_tag "upgrade_fail");
|
|
|
|
|
|
2018-05-11 15:56:47 +00:00
|
|
|
# handle bootloader, if requested; set longer timeout as sometimes
|
|
|
|
|
# reboot here seems to take a long time
|
Test upgrade of FreeIPA server and client deployment
Summary:
This adds an upgrade variant of the FreeIPA tests, with only
the simplest client enrolment (sssd) for now. The server test
starts from the N-1 release and deploys the domain controller
role. The client test similarly starts from the N-1 release
and, when the server is deployed, enrols as a domain client.
Then the server upgrades itself, while the client waits (as the
server is its name server). Then the client upgrades itself,
while the server does some self-checks. The server then waits
for the client to do its checks before decommissioning itself,
as usual. So, summary: *deployment* of both server and client
occurs on N-1, then both are upgraded, then the actual *checks*
occur on N.
In my testing, this all more or less works, except the role
decommission step fails. This failure seems to be a genuine one
so far as I can tell; I intend to file a bug for it soon.
Test Plan:
Run the new tests, check they work. Run the existing
FreeIPA tests (both the compose and the update variants), check
they both behave the same.
Reviewers: jsedlak, jskladan
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1204
2017-05-17 19:39:45 +00:00
|
|
|
if (get_var("GRUB_POSTINSTALL")) {
|
2018-05-11 15:56:47 +00:00
|
|
|
do_bootloader(postinstall=>1, params=>get_var("GRUB_POSTINSTALL"), timeout=>120);
|
2016-07-08 15:56:57 +00:00
|
|
|
}
|
Test upgrade of FreeIPA server and client deployment
Summary:
This adds an upgrade variant of the FreeIPA tests, with only
the simplest client enrolment (sssd) for now. The server test
starts from the N-1 release and deploys the domain controller
role. The client test similarly starts from the N-1 release
and, when the server is deployed, enrols as a domain client.
Then the server upgrades itself, while the client waits (as the
server is its name server). Then the client upgrades itself,
while the server does some self-checks. The server then waits
for the client to do its checks before decommissioning itself,
as usual. So, summary: *deployment* of both server and client
occurs on N-1, then both are upgraded, then the actual *checks*
occur on N.
In my testing, this all more or less works, except the role
decommission step fails. This failure seems to be a genuine one
so far as I can tell; I intend to file a bug for it soon.
Test Plan:
Run the new tests, check they work. Run the existing
FreeIPA tests (both the compose and the update variants), check
they both behave the same.
Reviewers: jsedlak, jskladan
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1204
2017-05-17 19:39:45 +00:00
|
|
|
|
|
|
|
|
# decrypt, if encrypted
|
2016-07-08 15:56:57 +00:00
|
|
|
if (get_var("ENCRYPT_PASSWORD")) {
|
2018-05-11 15:56:47 +00:00
|
|
|
boot_decrypt(120);
|
Test upgrade of FreeIPA server and client deployment
Summary:
This adds an upgrade variant of the FreeIPA tests, with only
the simplest client enrolment (sssd) for now. The server test
starts from the N-1 release and deploys the domain controller
role. The client test similarly starts from the N-1 release
and, when the server is deployed, enrols as a domain client.
Then the server upgrades itself, while the client waits (as the
server is its name server). Then the client upgrades itself,
while the server does some self-checks. The server then waits
for the client to do its checks before decommissioning itself,
as usual. So, summary: *deployment* of both server and client
occurs on N-1, then both are upgraded, then the actual *checks*
occur on N.
In my testing, this all more or less works, except the role
decommission step fails. This failure seems to be a genuine one
so far as I can tell; I intend to file a bug for it soon.
Test Plan:
Run the new tests, check they work. Run the existing
FreeIPA tests (both the compose and the update variants), check
they both behave the same.
Reviewers: jsedlak, jskladan
Reviewed By: jsedlak
Subscribers: tflink
Differential Revision: https://phab.qa.fedoraproject.org/D1204
2017-05-17 19:39:45 +00:00
|
|
|
# in encrypted case we need to wait a bit so postinstall test
|
|
|
|
|
# doesn't bogus match on the encryption prompt we just completed
|
|
|
|
|
# before it disappears from view
|
2016-07-08 15:56:57 +00:00
|
|
|
sleep 5;
|
|
|
|
|
}
|
2015-05-13 11:00:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
|
|
|
|
return { fatal => 1 };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|
