Project

General

Profile

Actions
Copy link

action #33100

closed

[functional]test fails in gpg - potentially too short wait time

Added by rtsvetkov about 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
pcervinka
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 19
Start date:
2018-03-12
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-12-SP4-Server-DVD-aarch64-extra_tests_in_textmode@aarch64 fails in
gpg

Reproducible

Fails since (at least) Build 0232

Expected result

Last good: 0217 (or more recent)

Further details

Always latest result in this scenario: latest

Related issues 1 (0 open — 1 closed)

Has duplicate openQA Tests - action #32815: [sle][functional][easy] test fails in gpg - increase timeoutRejectedpcervinka2018-03-06

Actions
Actions
Copy link
 #1

Updated by pcervinka about 6 years ago

  • Assignee deleted (pcervinka)
Actions
Copy link
 #2

Updated by okurz about 6 years ago

  • Subject changed from test fails in gpg - potentially too short wait time to [functional]test fails in gpg - potentially too short wait time
  • Assignee set to pcervinka
  • Target version set to Milestone 17

Hi @pcervinka, you removed yourself as assignee without a comment. Could you please share why you removed yourself? Rado and me selected you because you are one of the maintainers of the test module so this is why you were our first choice. Was this wrong?

Actions
Copy link
 #3

Updated by pcervinka about 6 years ago

Thanks for the notice. This must definitely some error on my side, not sure why at the moment. Although I don't work with SP4 I will check that issue later. So far it didn't happen on SP2/SP3.

Actions
Copy link
 #4

Updated by okurz about 6 years ago

hm, sure it could be something 12SP4 specific problem but I doubt this is true. I consider it more likely that aarch64 is the culprit having different timing behaviour. I have the feeling that the many wait_still_screen 1 in the test module are not the most robust choice.

Actions
Copy link
 #5

Updated by pcervinka about 6 years ago

I agree that 'wait_still_screen' seems to be overused (it was my 1st contact with openQA that time). My current idea is to replace each step with assert screen (to avoid possible timing issues). What do you think?

The problem is that I don't have aarch64 worker available for my private openQA instance. Do you know who could lend me aarch64 for short time?

Actions
Copy link
 #6

Updated by okurz about 6 years ago

  • Has duplicate action #32815: [sle][functional][easy] test fails in gpg - increase timeout added
Actions
Copy link
 #7

Updated by pcervinka about 6 years ago

  • Status changed from New to In Progress
Actions
Copy link
 #8

Updated by okurz about 6 years ago

pcervinka wrote:

I agree that 'wait_still_screen' seems to be overused (it was my 1st contact with openQA that time). My current idea is to replace each step with assert screen (to avoid possible timing issues). What do you think?

Well, at best a console based test does not need to rely on any screen checks except when you really want to check the rendering of a UI. I suggest to use either wait_serial in combination with assert_script_run/script_run calls or do the actual test using something like expect.

The problem is that I don't have aarch64 worker available for my private openQA instance. Do you know who could lend me aarch64 for short time?

I guess "aarch64" is only triggering failures because it is slower. That should not mean you need to test on aarch64. For the purpose of simulating a slow aarch64 instance you can actually use qemu to emulate the architecture. If you really want to test on aarch64 then I suggest to lend a machine on orthos

Actions
Copy link
 #9

Updated by pcervinka about 6 years ago

I remember now, why is used wait_stil_screen so much. There are several options entered in one command in "question and answer" mode during key generation.

Ok, I will focus only on that particular line 73 with validat_screen_output.

Actions
Copy link
 #10

Updated by pcervinka about 6 years ago

Actions
Copy link
 #12

Updated by pcervinka about 6 years ago

  • Status changed from In Progress to Feedback

PR was merged, let's see next result on aarch64.

Actions
Copy link
 #13

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_in_textmode
https://openqa.suse.de/tests/1535915

Actions
Copy link
 #14

Updated by pcervinka about 6 years ago

  • Status changed from Feedback to In Progress
Actions
Copy link
 #15

Updated by pcervinka about 6 years ago

  • Status changed from In Progress to Feedback
Actions
Copy link
 #16

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_in_textmode
https://openqa.suse.de/tests/1588098

Actions
Copy link
 #17

Updated by pcervinka almost 6 years ago

  • Status changed from Feedback to Resolved

Seems to be fine, several openQA runs on ARM are without error.

Actions
Copy link
 #18

Updated by okurz almost 6 years ago

  • Target version changed from Milestone 17 to Milestone 17
Actions
Copy link
 #19

Updated by oorlov almost 6 years ago

  • Status changed from Resolved to Workable
Actions
Copy link
 #20

Updated by okurz almost 6 years ago

  • Target version changed from Milestone 17 to Milestone 19
Actions
Copy link
 #21

Updated by okurz over 5 years ago

  • Status changed from Workable to Resolved

I see last failure 3 months ago and no value in trying to hammer the same ticket because when the test would fail again I am sure we need to investigate the new root cause independantly

Actions
Copy link

Also available in: Atom PDF