action #28606
closed[sle][functional][hard] vnc_two_passwords fails when system clock triggers wait_screen_change
Added by okurz over 6 years ago. Updated about 6 years ago.
100%
Description
Observation¶
openQA test in scenario sle-15-Installer-DVD-x86_64-extra_tests_on_gnome@64bit fails in
vnc_two_passwords
Reproducible¶
Fails since (at least) Build 288.8
Expected result¶
Last good: previous build was fine: https://openqa.suse.de/tests/1279195#step/vnc_two_passwords/26 . Seems like sporadic issue?
Acceptance criteria¶
- AC1: High-level error message which is more helpful
Tasks¶
- Investigate issue, find the root cause
- Come up with solution and implement if easy, otherwise improve error message and create new ticket for implementation
Further details¶
Always latest result in this scenario: latest
Updated by okurz over 6 years ago
- Subject changed from [sle][functional]test fails in vnc_two_passwords - "Test died: Expected: 0, received: 0, 1 for view_only_pw", wut? to [sle][functional][medium]test fails in vnc_two_passwords - "Test died: Expected: 0, received: 0, 1 for view_only_pw", wut?
- Description updated (diff)
Updated by okurz over 6 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: extra_tests_on_gnome
http://openqa.suse.de/tests/1423306
Updated by okurz about 6 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: extra_tests_on_gnome
https://openqa.suse.de/tests/1475475
Updated by okurz about 6 years ago
- Due date set to 2018-03-13
- Priority changed from Normal to High
Updated by riafarov about 6 years ago
- Subject changed from [sle][functional][medium]test fails in vnc_two_passwords - "Test died: Expected: 0, received: 0, 1 for view_only_pw", wut? to [sle][functional][medium][sporadic] make vnc_two_passwords more stable - "Test died: Expected: 0, received: 0, 1 for view_only_pw", wut?
- Description updated (diff)
- Status changed from New to Workable
Updated by zluo about 6 years ago
- Status changed from Workable to In Progress
checked at https://openqa.suse.de/tests/1509722
no issues for now.
Updated by okurz about 6 years ago
- Status changed from Resolved to In Progress
keep in mind that this was seen as a sporadic issue so a single job says nothing.
Updated by zluo about 6 years ago
- Priority changed from High to Low
http://e13.suse.de/tests/397#step/boot_to_desktop/5
boot_to_desktop from DVD-Installer doesn't work.
Set it to low because of sporadic issue.
Updated by okurz about 6 years ago
- Status changed from Blocked to In Progress
- Priority changed from Low to High
no, please don't do that. It fails often enough to be at least high prio. https://openqa.suse.de/tests/1514560#step/vnc_two_passwords/28 is the latest failure in RC1C1. And please do not use "Blocked" unless there is another report elsewhere wich needs to be tracked and resolved to unblock here. I do not see this so setting back to "In Progress".
Updated by zluo about 6 years ago
In rc1, vnc_two_passwords failed, but for recent run it seems to be okay again.
https://10.160.0.207/tests/latest?distri=sle&machine=64bit&arch=x86_64&test=extra_tests_on_gnome&flavor=Installer-DVD&version=15#step/vnc_two_passwords/19
I will check this now.
Updated by zluo about 6 years ago
- Assignee changed from zluo to mkravec
@mkravec can you provide your input for this? I am not sure about reason, timeout for wait_screen_change?
thanks!
Updated by zluo about 6 years ago
Updated by zluo about 6 years ago
try following:
wait_still_screen;
my $c1 = wait_screen_change { type_string "string", 30};
my $c2 = wait_screen_change { mouse_click, 30};
if ($c1 != $c2 || $c1 != $opt->{change}) {
die "Expected: $opt->{change}, received: $c1, $c2 for $opt->{pw}";
}
--
increase timeout to 30 sec
Updated by mkravec about 6 years ago
- % Done changed from 0 to 50
If you increase timeout to 1 minute it will always fail. Test is failing because of this:
If you compare system clock with SP4 testrun:
- https://openqa.suse.de/tests/1517814#step/vnc_two_passwords/22 - SP4
- https://openqa.suse.de/tests/1506981#step/vnc_two_passwords/22 - 15
wait_screen_change was designed for installation. You have to figure out how to hide system clock if you want to use it reliably after installation.
Updated by zluo about 6 years ago
I tested yesterday quite long time on loewe with total 10 remote workers. I found out that it might be to do with server performance. If I send more than 10 jobs and all remote-workers are running at same time, then it failed mostly. If I send single job, it just works fine.
So I think this is something which is quite difficult to localize where in code and how to improve code...
@mkravec please provide your input, thanks.
Updated by mkravec about 6 years ago
- Subject changed from [sle][functional][medium][sporadic] make vnc_two_passwords more stable - "Test died: Expected: 0, received: 0, 1 for view_only_pw", wut? to [sle][functional][medium][sporadic] vnc_two_passwords does not hide system clock
Updated by zluo about 6 years ago
- Assignee changed from mkravec to zluo
@mkravec, thanks.
to hide system top bar should the resolution after we talked about this... investigate how to hide top bar, at least disable showing the clock.
Updated by zluo about 6 years ago
I cannot find a way to hide gnome top bar atm...
Updated by mgriessmeier about 6 years ago
- Due date changed from 2018-03-13 to 2018-03-27
- Assignee deleted (
zluo) - Target version changed from Milestone 14 to Milestone 15
Updated by okurz about 6 years ago
- Subject changed from [sle][functional][medium][sporadic] vnc_two_passwords does not hide system clock to [sle][functional][medium][sporadic] vnc_two_passwords fails because the clock changes when the screen is expected to not check, we can not hide the system clock in more recent gnome
- Assignee set to mkravec
So apparently the problem is that the test relies on the full screen view to not change during a waiting time of 10 seconds. For this in the SLE12 case the test tweaked the gnome theme to hide the system clock. I researched and failed to find a feasible way (other than recompiling gnome) to hide the system clock.
@mkravec Can you explain why the test needs this? Or do you have an alternative in mind?
Updated by mkravec about 6 years ago
- Subject changed from [sle][functional][medium][sporadic] vnc_two_passwords fails because the clock changes when the screen is expected to not check, we can not hide the system clock in more recent gnome to [sle][functional] vnc_two_passwords fails when system clock triggers wait_screen_change
- Priority changed from High to Normal
Updated by okurz about 6 years ago
- Has duplicate action #16652: [sle][functional][ppc64le]test fails in vnc_two_passwords on Power trying to type the password added
Updated by okurz about 6 years ago
@mkravec Can you explain why the test needs this? Or do you have an alternative in mind?
Updated by mkravec about 6 years ago
@okurz, recompile gnome to hide clock? What about gnome extensions?
You can find information about current implementation in original poo#11794 (mentioned in test module). I am trying the alternative.
Updated by nicksinger about 6 years ago
- Subject changed from [sle][functional] vnc_two_passwords fails when system clock triggers wait_screen_change to [sle][functional][hard] vnc_two_passwords fails when system clock triggers wait_screen_change
Updated by okurz about 6 years ago
mkravec wrote:
@okurz, recompile gnome to hide clock? What about gnome extensions?
yes, these are the two ways I know about but I wonder what is actually wanted here. Isn't there a way for us to test something without relying on wait_still_screen?
Updated by mkravec about 6 years ago
okurz wrote:
Isn't there a way for us to test something without relying on wait_still_screen?
Comment #31 - "I am trying the alternative"
Updated by mkravec about 6 years ago
- % Done changed from 50 to 100
Updated by mkravec about 6 years ago
- Status changed from In Progress to Resolved
Updated by okurz about 6 years ago
- Status changed from Resolved to In Progress
According to our DoD we should keep the ticket open until we verified on production. I have merged the missing needle MR https://gitlab.suse.de/openqa/os-autoinst-needles-sles/merge_requests/763 as well now. Let's see how a retriggered test will cope: https://openqa.suse.de/tests/1543511
Updated by okurz about 6 years ago
- Status changed from In Progress to Resolved
so one test passed, so far so good. Let's assume we are good. Thank you very much.