action #35688
closed
coordination #35302: [qe-core][opensuse][functional][epic][sporadic] Various unstable tests on o3
[opensuse][functional][u][sporadic][bsc#1091353][medium] Various unstable tests on o3 - inkscape
Added by okurz about 6 years ago.
Updated about 4 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 18
Description
Observation¶
Problem¶
okurz: regarding "inkscape failing" I can always find the same symptoms, pkcon can not find the package but apparently a retrigger helps. I would consider that a product bug but we should help with investigation and workaround. E.g. in https://openqa.opensuse.org/tests/662319#step/inkscape/12
[30 Apr 2018 11:02:46] <DimStar> okurz: surprisingly this does not match PK's own log file, where in that same test it can find inkscape:
[30 Apr 2018 11:02:50] <DimStar> 2018-04-24 18:18:44 <1> susetest(2205) [packagekit] pk-backend-zypp.cpp(backend_resolve_thread):2825 inkscape ~installed;newest;arch;~source
[30 Apr 2018 11:02:52] <DimStar> 2018-04-24 18:18:44 <1> susetest(2205) [packagekit] pk-backend-zypp.cpp(backend_resolve_thread):2853 found (581)inkscape-0.92.2-6.2.x86_64(@System)
[30 Apr 2018 11:03:36] <DimStar> […] y2logs_clone contains it
Suggestions¶
might be also interesting to find log files in 'success case' (preferably of a direct rerun where it succeeded)
- Subject changed from [opensuse][functional][u][sporadic] Various unstable tests on o3 - inkscape to [opensuse][functional][u][sporadic][bsc#1091353] Various unstable tests on o3 - inkscape
- Status changed from In Progress to Blocked
First, I found that one process died with a core dump and reported this is a bug although I assume it's not directly related: https://bugzilla.opensuse.org/show_bug.cgi?id=1091349
I compared both pk_backend_zypp logfiles from a "bad" as well as "good" case and could find obvious differences but I did not investigate further in detail. https://bugzilla.opensuse.org/show_bug.cgi?id=1091353 reported. For now waiting for feedback in bug. Maybe someone has an idea.
If not, what we can try to do here now is to apply a workaround. I suggest to conduct the following steps:
- Reproduce locally consistently
- Crosscheck if the same can happen in clean installation systems or only the upgrade scenarios
- Reduce number of modules executed to simplify scenario
- Restart even more? Wait longer in between? Restart computer?
- Related to action #19428: [opensuse][functional][u][sporadic][medium] test fails in inkscape, pkcon xterm window does not close on "alt-f4" added
- Related to action #30805: [functional][opensuse][leap][medium][u] first test after reboot fails in krunner, potential system overload (was: test fails in inkscape - typing too fast?) added
- Due date changed from 2018-05-22 to 2018-06-05
can you clarify why exactly this is blocked?
it's not clear to me
- Due date changed from 2018-06-05 to 2018-07-03
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
- Target version changed from Milestone 16 to Milestone 17
I set it to be blocked by the bug mentioned in the subject line but the "gnome team" is apparently not very keen to pick it up so we should make sure that the inkscape test is stable regardless of this bug, i.e. even if that shows, keep the test stable, e.g. by reverting to zypper or whatever.
- Target version changed from Milestone 17 to Milestone 17
- Subject changed from [opensuse][functional][u][sporadic][bsc#1091353] Various unstable tests on o3 - inkscape to [opensuse][functional][u][sporadic][bsc#1091353][medium] Various unstable tests on o3 - inkscape
- Status changed from Workable to In Progress
- Assignee set to zluo
- Status changed from In Progress to Feedback
after long time investigation I found this is related more to worker performance than to test module itself or there is small regression issue of product.
tested on loewe and my remote worker.
test runs have failed mostly at installation stage "await_install" or "first_boot".
send_key_until_needlematch 'generic-desktop', "alt-f4", 5, 5;
Changes above can reduces failures on 3o, but it doesn't solve this problem really. We need a better resolution.
Set it as feedback for now.
- Due date changed from 2018-07-03 to 2018-07-31
- Status changed from Feedback to Blocked
- Target version changed from Milestone 17 to Milestone 18
I have the suspicion that most if not all unstable test modules fail due background maintenance tasks which are triggered during random time when test modules are executed so we should do #31351 first.
- Status changed from Blocked to Resolved
- Assignee changed from zluo to okurz
- Due date deleted (
2018-07-31)
Also available in: Atom
PDF