Commit Graph

31 Commits

Author SHA1 Message Date
akatch
2c427618ac
8.6 release fixes ()
* Handle the "reclaim space" dialog

Adds handling for the "Reclaim Space" dialog, which can appear after the
user clicks "Done" in the partitioning spoke.

* Fix indentations

* Set default HDD size to 15GB

* Remove redundant HDDSIZEGB definitions

* Add more GiBs

* Workaround for 

* Needle with new security policy spoke icon

* Add new needles to fix cockpit tests in 8.6

* Add contribution SOP to README

* Words

* Script fixes ()

* Increment version

* Fix this header

* Fix URL for updates.img ()

* ---
title: [8.6 Release Issues] Test Suite: install_delete_partial and install_custom_gui_lvm_ext4 on rocky 8.6
labels: 'test suite'
assignees: '@akatch'

---

# Description

Running openQA test suite `install_delete_partial` as above throws `Test died: no candidate needle with tag(s) 'anaconda_install_destination_reclaim_space_btn' matched` at module `disk_guided_delete_partial`.

At this stage, the "Reclaim Space" button in the lower right corner of the dialog is disabled.

Additionally, the dialog shows that 5GB will be reclaimed by the steps taken to that point in the test, but installation requires around 9GB. Do we need to reclaim enough space for installation in order to enable that button?
_Yes, the button is enabled when enough space to install is reclaimed._

Just adding HDDSIZEGB=20 to `templates.fif.json` did not increase volume size shown in the dialog. Do we need to recreate the img file?
_Yes, recreating the img file using createhdds.py against a larger size in hdds.json resolved this error._

The Reclaim Space dialog claimed 9.06GB was required to perform installation, and after doubling the size of disk_full_XXX.img we got past the Reclaim Space dialog. However, `_do_install_and_reboot` failed to install citing not enough disk space.

Fixes  when merged.

# How Has This Been Tested?

```
# NOTE: was not able to reproduce for install_custom_gui_lvm_ext4
openqa-cli api -X POST isos ISO=Rocky-8.6-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=dvd-iso VERSION=8.6 BUILD=8.6_dvd-iso_$(date +%Y%m%d.%H%M%S).0 TEST=install_custom_gui_lvm_ext4 PACKAGE_SET=graphical-server

openqa-cli api -X POST isos ISO=Rocky-8.6-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.6 BUILD=8.6_universal_$(date +%Y%m%d.%H%M%S).0 TEST=install_delete_partial PACKAGE_SET=graphical-server
```

All tests must pass `_do_install_and_reboot`.
NOTE: These tests will fail at `_console_wait_login` with the issue in .

# Checklist:

- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] Any dependent changes have been merged and published in downstream modules

* Add new needle to mitigate the changed default
for install source on the network from http to https

Co-authored-by: lumarel <lumarel@users.noreply.github.com>
2022-06-09 18:15:17 -05:00
Russ Butler
a5a3998ee9
Add test commands and expected results ()
Add a table with the test result from each product. Also add the
commands used to test each product.
2021-10-07 16:27:40 -05:00
2cca60ea79 minor updates to README.md for rocky 2021-08-09 22:18:49 -07:00
45b4b1072b minor updates to README.md and VARIABLES.md 2021-08-09 02:43:06 -07:00
Adam Williamson
cb3aa17b1a Note new test perl library requirements in README
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-06-18 09:48:24 -07:00
Adam Williamson
a171c588c5 Update two links in README (, thanks @defolos)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-10 16:05:00 -07:00
Adam Williamson
214f2cc8eb Add fifloader tests, template schemas, update README
This adds a test suite for fifloader (renamed fifloader.py for
test sanity). It adds JSON Schema form schemas for both FIF and
upstream openQA template data, and has fifloader (optionally,
but by default) validate both input and output data against the
schemas. It also adds a tox.ini configured to run the fifloader
tests, use fifloader to validate the template files, and do diff
coverage and lint checks. It also adjusts the Zuul config to run
tox instead of the test job.

There are also some pylint cleanups, since the new tests run
pylint.

fifcheck, fifconverter and tojson.pm are removed, as they were
mainly only needed for one-time conversion of the old format
templates; now they are in the git history we can always recover
them if we need them.

Along with all this I updated the README a bit to explain some
of it (and explain FIF better), and to explicitly state that this
repo is GPLv2+ licensed, and added GPL headers to some of the
files.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-29 22:45:38 -08:00
Adam Williamson
2c197d520c Add a whole intermediate template format ('FIF') and tools
I and @lruzicka (and I think @jskladan and @jsedlak and
@michelmno and everyone else who's ever touched it...) are being
gradually driven nuts by manually editing the test templates.
The bigger the files get the more awkward it is to keep them
straight and be sure we're doing it right. Upstream doesn't do
things the same way we do (they mostly edit in the web UI and
dump to file for the record), but we do still think making
changes in the repo and posting to the web UI is the right way
around to do it, we just wish the format was saner.

Upstream has actually recently introduced a YAML-based approach
to storing job templates which tries to condense things a bit,
and you can dump to that format with dump-templates --json, but
@lruzicka and I agree that that format is barely better for
hand editing in a text editor than the older one our templates
currently use.

So, this commit introduces...Fedora Intermediate Format (FIF) -
an alternative format for representing job templates - and some
tools for working with it. It also contains our existing
templates in this new format, and removes the old template files.
The format is documented in the docstrings of the tools, but
briefly, it keeps Machines, Products and TestSuites but improves
their format a bit (by turning dicts-of-lists into dicts-of-
dicts), and adds Profiles, which are combinations of Machines and
Products. TestSuites can indicate which Profiles they should be
run on.

The intermediate format converter (`fifconverter`) converts
existing template data (in JSON format; use tojson.pm to convert
our perl templates to JSON) to the intermediate format and
writes it out. As this was really intended only for one-time use
(the idea is that after one-time conversion, we will edit the
templates in the intermediate format from now on), its operation
is hardcoded and relies on specific filenames.

The intermediate format loader (`fifloader`) generates
JobTemplates from the TestSuites and Profiles, reverses the
quality-of-life improvements of the intermediate format, and
produces template data compatible with the upstream loader, then
can write it to disk and/or call the upstream loader directly.

The check script (`fifcheck`) runs existing template data through
both the converter and the loader, then checks that the result is
equivalent to the input. Again this was mostly written for one-
time use so is fairly rough and hard-coded, but I'm including it
in the commit so others can check the work and so on.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-24 15:21:23 +01:00
Adam Williamson
e771af455f One more Phab -> Pagure change (dangit) 2017-09-04 11:46:51 -07:00
Adam Williamson
c29c8e7129 More Phab -> Pagure updates 2017-09-04 11:46:15 -07:00
Adam Williamson
874757af9a Update README for retirement of Phabricator (use Pagure now) 2017-09-04 11:39:29 -07:00
Adam Williamson
92d588f245 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-02-22 11:33:32 -08:00
Adam Williamson
ed4720938f Yet more README updates 2017-02-14 16:12:17 -08:00
Adam Williamson
c9175b484a Some more README updates for repo changes 2017-02-14 16:08:21 -08:00
Adam Williamson
6d5b39afbf Update Phab project name in README.md 2017-02-14 16:04:08 -08:00
Adam Williamson
98536dedc9 Explain why phab project is called openqa_fedora 2017-02-10 09:28:13 -08:00
Adam Williamson
4c56971e64 More detailed instructions on Phabricator usage 2017-02-10 09:25:09 -08:00
Adam Williamson
b67f604894 Move all remaining utility functions into exporter modules
Summary:
This adds a couple of new exporter modules, renames main_common
to utils (this is a better name: openSUSE's main_common is
functions used in main.pm, utils is what they call their module
full of miscellaneous commonly-used functions), and moves a
bunch of utility functions that were previously needlessly
implemented as instance methods in base classes into the
exporter modules. That means we can get rid of all the annoying
$self-> syntax for calling them.

We get rid of `fedorabase` entirely, as it's no longer useful
for anything. Other base classes keep the 'standard' methods
(like `post_fail_hook`) and methods which actually need to be
methods (like `root_console`, whose behaviour is different in
anacondatest and installedtest).

Test Plan:
Do a full test suite run and check everything lines
up. There should be no functional differences from before at all,
this is just a re-org.

Reviewers: jskladan, garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames

Reviewed By: garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames

Subscribers: tflink

Differential Revision: https://phab.qa.fedoraproject.org/D1080
2017-01-17 23:15:44 -08:00
kparal
3e44c7b99f README: add a direct link to report issues in Phab 2017-01-13 12:59:06 +00:00
Adam Williamson
e393294b75 Go back to documenting PRs via Phab for now
Moving to Pagure for PRs and issues will require figuring out
a way to migrate existing ones over, so let's just stick with
Phab for now.
2017-01-12 14:56:36 -08:00
Adam Williamson
e0418b3328 Update and unwrap README, move function docs in-line
The README looks pretty ugly on Pagure. So let's unwrap it.
Let's also move the function docs into the source files. We're
much more likely to keep them up to date that way, I think. We
should probably change over to proper perl POD documentation at
some point, but comments in-line are OK for now I think.
2017-01-12 14:27:42 -08:00
Adam Williamson
0b147e169c Update some phab README links 2017-01-06 14:34:46 -08:00
Adam Williamson
bacb6f1f7b redo console_login with multiple matches, move to main_common
Summary:
Since we can match on multiple needles, we can drop the loop
from console_login and instead do it this way, which is simpler
and should work better on ARM (the timeouts will scale and
allow ARM to be slow here). Also move it to main_common as
there's no logical reason for it to be a class method.

Also remove the `check` arg. `check` was only set to 0 by two
tests, _console_shutdown and anacondatest's _post_fail_hook.

For _console_shutdown, I think I just wanted to give it the
best possible chance of succeeding. But we're really not going
to lose anything significant by checking, the only case where
check=>0 would've helped is if the 'good' needle had stopped
matching, and all sorts of other tests will fail in that case.

anacondatest was only using it to save a screenshot of whatever
was on the tty if it didn't reach a root console, which doesn't
seem that useful, and we'll get screenshots from check_screen
and assert_screen anyway.

Test Plan:
Run all tests, check they behave as expected and
none inappropriately fails on console login.

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1016
2016-09-30 08:42:45 -07:00
Adam Williamson
f59343403a add FreeIPA server role deploy and kickstart enrolment tests
Summary:
These require openQA tap networking to allow the server and
client boxes to communicate, and require masquerading (NAT) so
the server at least can reach a repository (dnf/rolekit really,
really do not want to work without a repo connection).

They use the 'parallel' test support to have the server deploy
run first while the client enrol test waits at the grub menu
until the server is done before it goes ahead.

This is all deployed and working on stg. The really tricky bit
was getting all the openvswitch and firewall config right in
ansible.

We *could* do the server deploy test as a follow-on from the
default install test to save the install, but then we'd have to
teach it to change the hostname and set up static networking
post-install. I'm not sure if it's worth doing that.

This requires the corresponding openqa_fedora_tools commit that
adds the hard disks (containing the kickstarts - it's possible
to get them from remote during install, but we have to set up
name resolution or hard code the IP of the server).

Test Plan:
Deploy this and the openqa_fedora_tools commit,
generate the disks, configure the networking (good luck! See
the docs in openqa_fedora_tools) and see if you can run the
tests. If you're using Docker, uh...sorry. You somehow need to
set things up so the workers can use tap interfaces that can
talk to each other and are NATed to the outside world. Have fun.
I can talk you through it on IRC...

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D831
2016-05-04 11:53:11 -07:00
Adam Williamson
b97c019ae9 revise language tag handling to be easier to use (T617)
Summary:
T617 makes some good points about the language tags; this is my
suggestion for an improvement. It requires a bit of cleverness
in unregister_prefix_tags(), but the upshot is that you don't
need to know to set any special tags when creating needles, a
needle with no language-related tags will be considered as valid
for all languages. You have to explicitly add LANGUAGE- tag(s)
to a needle for the language filtering to 'kick in' in any way.
If a needle has at least one LANGUAGE- tag, it will be filtered
unless it has the appropriate tag for the job's specified
language (default is still 'english').

With this approach, only needles which we specifically want to
*only* match their tagged language(s) need the tags, so we can
drop all those -ALL tags.

We're using LANGUAGE- instead of ENV-LANGUAGE- now because the
ENV- tag names denote tags that are treated slightly specially
by openQA, and this is not one. We cannot cleanly use
ENV-INSTLANG because openQA has a hardwired default of 'en_US'
for that.

Test Plan:
Check both English and French tests still work as
intended.

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D589
2015-09-29 15:52:50 -07:00
Adam Williamson
b3aa968575 add a french (encrypted) test
Summary:
this handles Non-English European Language Install. Basically
it's a bunch of new screenshots for existing tag names, plus
a bit of configurability in _boot_to_anaconda and tweaking some
existing needles to do non-text matches. The weird 'half-the-
icon' needles are for cases where there may or may not be a
warning triangle but we want to click it either way (saves
duplicating the needle).

This also sets up a convention for tagging what languages a
needle is appropriate for. If it's specifically appropriate for
one or more languages, a tag ENV-LANGUAGE-(LANGUAGE) should be
applied for each language, where (LANGUAGE) is the install
language in upper-case ('LANGUAGE' variable, which should also
be the string that will be typed into the language selection
screen). If the needle ought to be used for *all* languages -
i.e. it's not a text match, or any text in the match is known
not to be translated - the tag ENV-INSTLANG-ALL should be
applied.

To back this, main.pm now unregisters all needles that are not
tagged with either ENV-LANGUAGE-ALL or the tag for the language
actually being used (if the LANGUAGE var is not set, we assume
english). The point of this is to check the install is actually
translated; if we allow all needles to match, the test would
pass even if no translations appeared at all.

Test Plan:
Run all tests and make sure you get the expected
results. You can schedule a run against 23 Beta TC1 to see the
French test fails 'correctly' when translations are missing.

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D577
2015-09-14 18:08:58 -07:00
Jan Sedlák
81bedd8de7 update README - use wiki instead of PhaseSeparation.md
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D571
2015-09-11 12:36:20 +02:00
Adam Williamson
68acecb6d4 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 14:49:13 -07:00
Jan Sedlák
0942cd72a6 document utility methods
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D554
2015-09-04 11:00:31 +02:00
Jan Sedlák
5438b452d2 mention main.pm architecture in README
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D495
2015-08-11 13:30:42 +02:00
Jan Sedlák
e000209967 add comments and documentation
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D481
2015-08-05 08:23:59 +02:00