action #30210
closed[sle][functional][yast][y][medium]test fails in system_role due to initializing the installation is taken a long time
0%
Description
Observation¶
openQA test in scenario sle-15-Installer-DVD-ppc64le-lvm-full-encrypt@ppc64le fails in
system_role
Investigate why is taking more time than usual and and see if it is needed to increase the timeout or could be a bug and also check if it is sporadic or not.
Reproducible¶
Fails since (at least) Build 288.8
Expected result¶
Latest result is passed: https://openqa.suse.de/tests/1549089#step/system_role/1
Further details¶
Always latest result in this scenario: latest
Updated by okurz almost 7 years ago
- Subject changed from test fails in system_role due to initializing the installation is taken a long time to [sle][functional]test fails in system_role due to initializing the installation is taken a long time
- Due date set to 2018-03-27
- Target version set to Milestone 15
Updated by okurz almost 7 years ago
- Due date changed from 2018-03-27 to 2018-04-10
- Priority changed from Normal to High
Updated by okurz almost 7 years ago
- Subject changed from [sle][functional]test fails in system_role due to initializing the installation is taken a long time to [sle][functional][yast][y]test fails in system_role due to initializing the installation is taken a long time
Updated by okurz almost 7 years ago
- Due date changed from 2018-04-10 to 2018-03-27
adding late to S13 as we have capacity.
please find "last good". Look for statistics and compare architectures, e.g. how often and where it happens.
Updated by okurz almost 7 years ago
- Subject changed from [sle][functional][yast][y]test fails in system_role due to initializing the installation is taken a long time to [sle][functional][yast][y][medium]test fails in system_role due to initializing the installation is taken a long time
- Description updated (diff)
- Status changed from New to Workable
Updated by mloviska almost 7 years ago
- Status changed from Workable to In Progress
- Assignee set to mloviska
Updated by mloviska almost 7 years ago
lvm-full-encrypt¶
ppc64 previous results:
lvm-full-encrypt@ppc64le
- got stucked only once during initialization of the installation ppc64le-Build414.13-lvm-full-encrypt@ppc64le, Assigned worker: malbec:4
s390x previous results:
lvm-full-encrypt@s390x-kvm-sle12
- no occurence of test error on system_role module
x86-64 previous results:
lvm-full-encrypt@64bit
- 1 test error Build393.1-lvm-full-encrypt@64bit, missing option for DESKTOP=gnome test case (SLES with GNOME)
Aarch64 previous results from build 503.1:
lvm-full-encrypt@aarch64
- no occurence of test error on system_role module
I have chosen as another reference create_hdd_gnome and create_hdd_textmode jobs.
create_hdd_gnome¶
ppc64 previous results:
create_hdd_gnome@ppc64le
- no occurence of test error on system_role module
s390x previous results:
create_hdd_gnome@s390x-kvm-sle12
- no occurence of test error on system_role module
x86-64 previous results:
create_hdd_gnome@64bit
- 1 test error Build393.1-create_hdd_gnome@64bit, missing option for DESKTOP=gnome test case (SLES with GNOME)
Aarch64 previous results:
create_hdd_gnome@aarch64
- 1 test error Build393.1-create_hdd_gnome@aarch64, missing option for DESKTOP=gnome test case (SLES with GNOME)
create_hdd_textmode¶
ppc64 previous results:
create_hdd_textmode@ppc64le
- no occurence of test error on system_role module
s390x previous results:
create_hdd_textmode@s390x-kvm-sle12
- no occurence of test error on system_role module
x86-64 previous results:
create_hdd_textmode@64bit
- Build429.1-create_hdd_textmode@64bit, yast2 font change issue
- Build303.1-create_hdd_textmode@64bit, unmatched needle
Aarch64 previous results from build 503.1:
create_hdd_textmode@aarch64
- Build299.1-create_hdd_textmode@aarch64, partition manager appeared instead of system role
- Build300.1-create_hdd_textmode@aarch64, partition manager appeared instead of system role
- Build303.1-create_hdd_textmode@aarch64, unmatched needle
ppc workers used with build 509.1:¶
QA-Power8-4-kvm:1
QA-Power8-4-kvm:2
QA-Power8-4-kvm:3
QA-Power8-4-kvm:4
QA-Power8-4-kvm:5
QA-Power8-4-kvm:6
QA-Power8-4-kvm:7
QA-Power8-4-kvm:8
QA-Power8-5-kvm:1
QA-Power8-5-kvm:2
QA-Power8-5-kvm:3
QA-Power8-5-kvm:4
QA-Power8-5-kvm:5
QA-Power8-5-kvm:6
QA-Power8-5-kvm:7
QA-Power8-5-kvm:8
powerqaworker-qam-1:1
powerqaworker-qam-1:2
powerqaworker-qam-1:3
powerqaworker-qam-1:4
powerqaworker-qam-1:5
Conclusion¶
IMHO it looks like more a worker issue than bug in a test or product.
Worker malbec:4 has not been used over a month and according to its history it had multiple incomplete and error job runs around the time when this job ran.
This type of error has not been observed on any other architecture.
Updated by okurz almost 7 years ago
Very good investigation and good conclusion. Yes, malbec produced quite some "worker specific" problems and I am fine with closing this ticket as "resolved" with the resolution being that malbec was disabled anyway and therefore we do not see a necessary action on the side of tests. I think the QA tools team is on the task to bring malbec back. I hope they do as good a job as they did when they brought in workers in before, that is having them run in a confined environment until they have proven themselves stable enough for production work :)
Updated by mloviska almost 7 years ago
- Status changed from In Progress to Resolved
Alright, let's then wait for tool team. Thank you Oli! :)