coordination #34858
closed
[functional][sle][opensuse][y][epic] Ensure HDD sizes are consistent and have a reasonable relation to product specifications
Added by okurz about 6 years ago.
Updated over 3 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 25
Estimated time:
(Total: 0.00 h)
Description
Motivation¶
Please read https://bugzilla.suse.com/show_bug.cgi?id=1089274#c10 . The bug is about inability to calculate a partition proposal but was appearing only on aarch64 and s390x. For aarch64 because apparently the machine does never override the default HDDSIZEGB from os-autoinst and s390x because the failing tests rely on DASD devices defined on the mainframe no matter what one selects as HDDSIZEGB
Acceptance criteria¶
- AC1: The test results for different architecture do not differ just because the storage sizes differ
- AC2: There are explicit scenarios to test the minimum (or at least minimum recommended) specifications (see s390x low ram one as example)
Suggestions¶
- Take a look on https://openqa.suse.de/admin/machines and query for HDDSIZEGB
- Compare to settings on o3
- Delete the setting where it is equal to 10 which is the os-autoinst default anyway
- Make sure the default test scenarios have corresponding HDD sizes or put a comment on the machine definitions (special value _COMMENT=…) why we need weird settings, e.g. find out why we have HDDSIZEGB=24 on svirt-kvm-uefi
- Make sure the available spaces on remote machine tests, especially zVM, are corresponding to the settings on other tests and archs
- Add specific scenarios to cover the lower borders (e.g. minimum product specification + small safety margin)
- Crosscheck shortly the same for RAM
- Subject changed from [functional][sle][y] Ensure HDD sizes are consistent and have a reasonable relation to product specifications to [functional][sle][opensuse][y] Ensure HDD sizes are consistent and have a reasonable relation to product specifications
- Priority changed from Normal to High
FYI:
- MicroOS-10G-disk (uses HDDSIZEGB=10)
updated zkvm and s390x-kvm-sle12 and s390x-kvm-sle15 to have 20GB as well. For SLE15 build 567.1 I retriggered all s390-kvm jobs that failed in partitioning_finish by finding them in the test overview and using the job ids:
for i in 1618742 1618737 1618754 1618791 1618796 1618788 1618816 1618743 1618767 1618811 1618855 1618856 1618817 1618744 1618814 1618770 ; do openqa_clone_job_osd $i HDDSIZEGB=20 ; done
- Status changed from New to Workable
- Assignee set to riafarov
- Subject changed from [functional][sle][opensuse][y] Ensure HDD sizes are consistent and have a reasonable relation to product specifications to [functional][sle][opensuse][y][fast] Ensure HDD sizes are consistent and have a reasonable relation to product specifications
- Related to action #34894: [sle][functional][u][fast] Make sure aarch64 job represent expected default for HDDSIZEGB=20 added
- Related to action #34888: [functional][sle][u][s390x][zvm] Make sure s390x DASD devices used for testing represent our expected default ~20GB added
- Priority changed from High to Normal
- Subject changed from [functional][sle][opensuse][y][fast] Ensure HDD sizes are consistent and have a reasonable relation to product specifications to [functional][sle][opensuse][y][epic] Ensure HDD sizes are consistent and have a reasonable relation to product specifications
Immediate issues are resolved, will handle it in Milestone 17
- Assignee deleted (
riafarov)
- Target version changed from Milestone 17 to Milestone 21+
- Target version changed from Milestone 21+ to Milestone 21+
- Target version changed from Milestone 21+ to Milestone 23
rbrown talked with me yesterday. He stated that starting qemu with "20GB" gives only 18.something GB so he plans to update the openQA machine definitions on o3 to have 22GB. We should probably have the same on osd then.
- Due date set to 2019-03-26
due to changes in a related task
- Due date changed from 2019-03-26 to 2019-06-18
due to changes in a related task
- Target version changed from Milestone 23 to Milestone 25
- Status changed from Workable to Resolved
- Assignee set to riafarov
- Tracker changed from action to coordination
Also available in: Atom
PDF