Commit Graph

326 Commits

Author SHA1 Message Date
Adam Williamson
517750443e Remove RHBZ #1638563 workaround
The fix for this bug was sent to all releases now, so we should
not need the workaround any more. Let's kill it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-17 12:02:57 -08:00
Adam Williamson
0498f4db94 Use 30s timeout on the check_screen in the workaround
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-13 15:29:35 -08:00
Adam Williamson
b3f51e6108 Gah come back missing bracket
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-13 15:23:50 -08:00
Adam Williamson
1f7e5ebe20 Attempt a workaround for RHBZ#1659266
This is breaking the memory_check tests. I just reproduced it
manually and the UI *does* come back to life if you wait some
time; let's see if we can work around the bug this way.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-13 15:15:49 -08:00
Adam Williamson
12e103e3da Factor meat out of advisory_post and do it in postfail too
If an update test fails before reaching advisory_post, we don't
generate the 'what update packages were installed' and 'were
any update packages *not* installed when they should have been'
logs, but these may well be useful for diagnosing the failure -
so let's also do the same stuff there. Only let's not do it all
twice.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-12 22:17:29 -08:00
Adam Williamson
764c6dbd95 Notice when update package should have been installed but wasn't
We hit an interesting case in update testing recently:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-115068f60e

An earlier version of that update failed testing. When we dug
into it a bit, we found that the test was failing because an
earlier version of the `pki-server` package was installed than
the version that was in the update; when asked (as part of
FreeIPA deployment) to install it, dnf had noticed that there
were dependency issues with the version of the package from the
update, but it happened to be able to install the version from
the frozen 'stable' repo...so it just went ahead and did that.

In this case, the 'missed' package resulted in a test failure,
but it'd actually be possible for this to happen and the test
to complete; we really ought to notice when this happens, and
treat it as a test failure.

So what this attempts to do is: at the end of all update tests,
check for all installed packages with the same name as a package
from the update, and compare their full NEVR to the one of the
package from the update. If a package with the same name as one
of the update packages is installed, but does not appear to be
the *same NEVR*, we fail, and upload the lists of packages for
manual investigation as to what the heck's going on.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-12-12 22:17:29 -08:00
Adam Williamson
e76ad4bbc1 Crank sss debuglevel up to 9, and also do it for cockpit test
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-11-30 14:58:53 -08:00
Adam Williamson
14ad5b97f1 Still try and upload testedpkgs even if comm 'fails'
From local experimentation, it still actually produces the
output, even though it prints the message about the order being
wrong and exits 1.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-11-08 17:46:45 -08:00
Adam Williamson
ddf6ba5a6b update tests: don't fail if comm is unhappy about the alphabet
Weirdly, occasionally some update tests seem to fail because
the 'comm' util we use to produce the list of packages from the
update that were actually tested during the job doesn't think
one of the input files is in alphabetical order, even though we
sort them both when they're produced. I don't know if this is
possibly due to the definition of 'alphabetical order' changing
as part of the update, or what. But we really shouldn't *fail*
the test when this happens, as it's not part of the functional
test, we're just producing convenience data. So, let's handle
the command failing, and if it happens, upload the input files
so we can maybe figure out why it's unhappy...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-11-08 16:59:06 -08:00
Adam Williamson
70ef3404f0 Tweak previous commit to avoid some bugs
The previous commit would lead to the 'workaround' getting hit
incorrectly, and might have had some other issues...tweak it a
bit.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-31 12:45:11 -07:00
Adam Williamson
fd753b2e3a Handle split of 'download' and 'apply' phases in gnome-software
GNOME Software 3.30.5 split the offline update process into two
separate 'download' and 'apply' phases. So we need to handle
clicking 'download' before 'apply', if that happens.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-31 11:50:14 -07:00
Adam Williamson
e6c8c5f0ff Work around Firefox 'close multiple tabs' warning
Somehow, recently, FreeIPA tests are running into Firefox not
quitting because it's showing a warning about closing multiple
tabs. (I think we didn't *get* multiple tabs before but now we
do, for some reason). So let's work around this by clicking
"Close tabs" if the warning appears.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-30 18:34:37 -07:00
Adam Williamson
129d1316a6 Fix tty switching for desktop_notifications
Lately, we can't be sure the desktop will be on tty1 after we
do 'systemctl isolate graphical.target'. For recent Workstation
lives it actually shows up on tty2.

We could be 'clever' and switch to tty2 on F29+ Workstation
lives...but actually it seems like if we just don't do anything,
systemd switches us to the correct tty. So let's rely on that,
at least as long as it's working.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-12 21:16:33 -07:00
Adam Williamson
22c0b5bc04 Disable hidden grub menu for uploaded base installs
At least one test (desktop_notifications_postinstall) boots from
the disk image uploaded by install_default_upload, and needs to
access the grub menu. On F29+ Workstation this is failing,
because the grub menu is now hidden by default, so when the test
boots, it never sees the bootloader screen, and fails.

I considered trying to teach it to hold down shift or hit f8 or
esc at the right time, but that seems like it might be hard. So
instead let's just try to disable the hidden menu when we're
about to upload the installed system image. This is kinda going
against the 'preserve natural system behaviour' principle we try
to use for openQA, but I think it's OK as we do have other tests
that will exercise the 'hidden boot menu' stuff to some extent.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-12 15:36:55 -07:00
Adam Williamson
17b6d9f708 Tweak the workaround to work for F27 too
On F27 we don't get a 'Software is up to date' screen because
there's an upgrade available. Let's work with the refresh button
instead.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-11 22:23:53 -07:00
Adam Williamson
63d8f34a0e Tweak the workaround loop a bit, refresh the comments
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-11 16:18:04 -07:00
Adam Williamson
db4ab638da Restore modified version of the #1314991 workaround for #1638563
We're not seeing *exactly* #1314991 any more, but we're seeing
something that looks quite similar: the first attempt to find
updates just doesn't find any. No error message, no updates. I
have reported a bug for this and am investigating it, in the
meantime, let's restore the workaround, elaborated a bit, and
looking for the 'Software is up to date' screen instead of the
error message.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-11 16:07:58 -07:00
Adam Williamson
25ad8a6aeb Drop workaround for #1314991, it doesn't work any more
I rather suspect the *bug* is still basically present and it's
why this test often fails, but we no longer seem to see the
*error message* which lets us detect the bug happening. This
needle has not been hit by any test for six months. So let's
remove the workaround as it adds complexity.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-10 13:45:51 -07:00
Adam Williamson
9869920f5b Use longer timeout for root console switch after liveinst
For some reason, in recent tests, switching to a console after
live install completes is taking a long time, and tests are
failing because we 'only' allow 10 seconds for the login prompt
to appear. This seems to indicate some kind of performance bug,
but we don't really want all liveinst tests to fail on in, this
is not primarily a performance testing framework. So let's
tweak the root_console / console_login bits a bit to allow a
configurable timeout for the login prompt to appear, and use
that to wait 30 secs instead of 10 in this case.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-06 08:44:34 -07:00
Adam Williamson
6e262be28b Add a check that FreeIPA is actually up after upgrade
The FreeIPA upgrade test didn't actually check that FreeIPA is
actually running after the upgrade and reboot, it just kinda
assumed it is. Let's add a check to the start of the 'check'
test module that makes sure ipa.service actually comes up to
'active' state. This'll make it clearer when tests are failing
because FreeIPA didn't come up right after the upgrade. The
check will run on non-upgrade tests too, but that's fine.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-05 23:53:17 -07:00
Adam Williamson
0bf76db7d5 Add a test of bootchain stuff for updates
This adds a new test intended to just check boot chain things
for updates. It doesn't run any test modules besides the stock
update ones, but sets a variable, ADVISORY_BOOT_TEST, which
causes _advisory_update to do some additional stuff after
installing the updates but before rebooting: it forces regen
of the initramfs and bootloader config, and reinstalls the
bootloader on BIOS (not UEFI as it's not relevant). If the
following boot fails, we probably have a bug somewhere.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-04 16:43:15 -07:00
Adam Williamson
d2d6bfa695 Try something different for screen corruption after IPA uninstall
There's this annoying problem where the screen sometimes goes
messed up after ipa-server-uninstall. 'clear' doesn't seem to
really work to fix it up either. Let's try flipping between
ttys. I don't like this much as it's already a pain trying to
work out / remember what tty we might possibly be on at any
given time, but I think we're always on either 1 or 3 here, so
let's do ctrl-alt-f1 ctrl-alt-f3 to ensure at least one change
and wind up on tty3...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-28 18:09:58 -07:00
Adam Williamson
c2fb886d6f Add another wait to avoid a transition animation in anaconda
I swear, these transitions drive me nuts.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-28 17:46:36 -07:00
Adam Williamson
a49f328dc6 Tweak how update-upgrade tests are handled a bit
Looking at this, it's a bit weird: the updated packages are
actually included in the upgrade process, but we still run
_advisory_update, which does basically nothing...then reboots.
That's kinda silly and makes the tests a bit flaky, let's fix
it. I don't think there's actually any problem with doing the
upload of updatepkgs.txt in _repo_setup_updates, becase that
already guards against being run more than once, it just bails
very early if it's already been run.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-28 17:23:51 -07:00
Lukas Ruzicka
24e68aa8a2 Create openqa tests to test modularity. 2018-09-26 23:09:36 -07:00
Adam Williamson
923267574d Drop the workaround for #1625572
It's fixed everywhere now, and the workaround can misfire if
the first g-i-s is slow quitting (see
https://openqa.fedoraproject.org/tests/280482)
2018-09-16 08:39:30 -07:00
Adam Williamson
f334df1337 Bump ipa-replica-install timeout a bit (it takes a long time)
I'm going to figure out if it's a bug that it takes so long, but
for now let's just bump the timeout.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-07 15:56:11 -07:00
Adam Williamson
e2eb794a87 Tweak the workaround yet again (with soft fail this time)
Sigh, sorry, just perfecting. This way it won't fail when the
bug is fixed (hopefully).

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 20:36:29 -07:00
Adam Williamson
7dff1843db Tweak that workaround again (forgot the version check)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 19:53:07 -07:00
Adam Williamson
211cc221b3 Rejig the 1625572 workaround to just use an existing conditional
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 19:00:49 -07:00
Adam Williamson
af6b9b15aa Gah, fix version testing in previous commit
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 18:23:13 -07:00
Adam Williamson
5a48086e61 Don't expect GDM when doing GNOME no-user install on F28+
GNOME now transitions straight from the g-i-s 'user creation'
mode to a logged-in desktop.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 18:21:12 -07:00
Adam Williamson
e3887c5a83 Work around RHBZ#1625572 (both g-i-s modes running)
RHBZ#1625572 is for gnome-initial-setup running in 'first login'
mode after it's already run in 'user creation' mode (which isn't
meant to happen). This works around that so the subsequent tests
can run. We don't soft-fail because meh.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 17:59:40 -07:00
Adam Williamson
c62a04bac8 Remove old workaround for g-i-s failing to run on F26
This hasn't been a problem for ages.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 17:49:03 -07:00
Adam Williamson
cc2f1a3cec _graphical_wait_login: drop an old FAW workaround
This bug was fixed long ago, we no longer need the workaround.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 15:02:20 -07:00
Adam Williamson
64c5070b06 Simplify _graphical_wait_login by dropping a huge conditional
If USER_LOGIN is false we can just return; when we reach the
login screen. We don't need a huge conditional when we don't do
anything *after* it, in the false case.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-09-06 15:01:08 -07:00
Adam Williamson
cfe2a33038 Have domain controller upload logs *before* decommissioning
It transpires that decommissioning wipes some stuff, like the
dirsrv logs. Obviously we want these included in the logs we
upload for reference purposes, so let's upload earlier.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-08-24 14:42:52 -07:00
Adam Williamson
bdd26a09ee Have kickstart tests handle RHBZ#1618928 too
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-08-19 10:03:27 -04:00
Adam Williamson
9df64398ee Add a FreeIPA replication job set
This adds a set of jobs to test FreeIPA replication. We deploy
a server, deploy a replica of that server, then enrol a client
against the replica and run the client tests.

At first I was planning to add the replica testing into the
main set of FreeIPA tests, but the test ordering/blocking (via
mutexes and barriers and what-have-you) just turns into a big
nightmare that way. This way seems rather simpler to deal with.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-08-02 09:59:40 -07:00
Adam Williamson
35caea44bc Revert "Try downgrading softhsm as a workaround for #1607635"
This reverts commit 0289716d70.
Turns out the downgrade doesn't avoid the crash. :(
2018-07-30 11:58:12 -07:00
Adam Williamson
0289716d70 Try downgrading softhsm as a workaround for #1607635
We'd really like to know if FreeIPA is working aside from this
crasher bug, so let's workaround it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-30 11:33:02 -07:00
Adam Williamson
acc4ccd7cc Add a sleep to desktop_update_graphical
Try and avoid failure to launch alt-f1 dialog...

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-30 11:23:59 -07:00
Adam Williamson
a479774026 Correct previous commit
Should be if, not unless...damn exit codes.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-23 14:08:37 -07:00
Adam Williamson
3817e7128d Work around RHBZ #1606541 (on Rawhide, not updates)
We kind of want to know if FreeIPA is working aside from this
known bug, so let's treat it as a soft failure and work around
it. But only for Rawhide, not for F27/F28 updates tests.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-23 11:12:57 -07:00
Adam Williamson
7621cd7e57 Move the new base_services_start check to the start
...otherwise we actually return before it, if no services fail.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-13 14:02:31 -07:00
Adam Williamson
b4cd1b4a9e Check for services deleted to break loops in base_services_start
https://bugzilla.redhat.com/show_bug.cgi?id=1600823 shows a
case where systemd throws a service that would usually have been
started out of the boot process *entirely* in order to resolve a
dependency loop. This means the service won't show up as failed,
it will just be inactive when it should be active. This still
should constitute a failure of this test, so let's add a check
for the log message that indicates this situation.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-13 13:37:04 -07:00
Adam Williamson
a362ecb2a0 Add a softfail workaround for #1600823
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-13 00:39:53 -07:00
Adam Williamson
9ae2c249f2 Stop using rolekit for database server role on F29+
As for the domain controller role, stop using rolekit on F29+,
as it's going away. Continue using it on <F29.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-10 17:54:30 -07:00
Adam Williamson
5999058d07 We should *not* check CURRREL for rolekit in _check
...because by this point in the upgrade test, the system is
upgraded, and rolekit won't be there on F29+.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-10 16:21:54 -07:00
Adam Williamson
7e7016ea14 Convert domain controller test not to use rolekit
Rolekit is going away. At least for the F29 cycle, though, we
still want to test basically the same functionality. This ports
the 'domain controller role' test to use ipa-server-install
directly rather than rolectl.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-07-09 19:54:49 -07:00