Project

General

Profile

Actions

action #10228

closed

timeout is too delicate on many occasions, especially partitioning_raid

Added by dmaiocchi over 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Start date:
2016-01-19
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:

Description

observation

e.g. in https://openqa.suse.de/tests/180178

suggestion

  • remove explicit timeout in partitioning_raid
  • also review other locations

Checklist

  • SLE
  • Leap
  • TW

Subtasks 2 (0 open2 closed)

action #10288: potentially too strict timeout in boot_encryptResolveddgutu2016-01-19

Actions
action #10294: potentially too strict timeout on call of "switch_console"Resolveddzedro2016-01-19

Actions
Actions #1

Updated by RBrownSUSE over 8 years ago

  • Checklist item changed from to [ ] SLE, [ ] Leap, [ ] TW
  • Priority changed from Normal to High
  • Target version set to 162
Actions #2

Updated by okurz over 8 years ago

potentially related https://openqa.suse.de/tests/181150/modules/partitioning_finish/steps/1
Actually not this one. I think the problem is a typo, see "after-paritioning". more related to different issue https://progress.opensuse.org/issues/9962

Actions #3

Updated by RBrownSUSE about 8 years ago

  • Status changed from New to Feedback
  • Assignee set to RBrownSUSE
Actions #4

Updated by okurz about 8 years ago

  • Status changed from Feedback to In Progress

not fixed, original issue appeared at exactly the same location: https://openqa.suse.de/tests/200677/modules/partitioning_raid/steps/97
can we just increase the timeout in

Debug: /var/lib/openqa/share/tests/sle/tests/installation/partitioning_raid.pm:43 called testapi::wait_screen_change
<<< wait_screen_change(timeout=10)
Actions #5

Updated by RBrownSUSE about 8 years ago

  • Assignee deleted (RBrownSUSE)

the new issue is not the same as the one that I fixed

https://openqa.suse.de/tests/200677/modules/partitioning_raid/steps/1/src
Line 40-44

I think this code block is redundant, and is too delicate, so caused this issue, as the sendkey_until_needlematch on line 162 will have the same end result when it gets to the last entry in the list

Can someone else please take care of it?

Actions #6

Updated by okurz about 8 years ago

  • Assignee set to okurz

on it

Actions #8

Updated by okurz about 8 years ago

  • Status changed from In Progress to Feedback

PR merged, let's wait for feedback from some tests, especially RAID on ppc64le

Actions #9

Updated by okurz about 8 years ago

  • Status changed from Feedback to Resolved

no further recent failures. reopen if still happens or create new one.

Actions #10

Updated by okurz about 8 years ago

  • Target version changed from 162 to Milestone 1
Actions

Also available in: Atom PDF