action #10228

timeout is too delicate on many occasions, especially partitioning_raid

Added by dmaiocchi about 4 years ago. Updated about 4 years ago.

Status:ResolvedStart date:19/01/2016
Priority:HighDue date:
Assignee:okurz% Done:

100%

Category:Bugs in existing tests
Target version:openQA Project - Milestone 1
Difficulty:
Duration:

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

action #10288: potentially too strict timeout in boot_encryptResolveddgutu

action #10294: potentially too strict timeout on call of "switch_console"Resolveddzedro

History

#1 Updated by RBrownSUSE about 4 years ago

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

#2 Updated by okurz about 4 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

#3 Updated by RBrownSUSE about 4 years ago

  • Status changed from New to Feedback
  • Assignee set to RBrownSUSE

#4 Updated by okurz about 4 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)

#5 Updated by RBrownSUSE about 4 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?

#6 Updated by okurz about 4 years ago

  • Assignee set to okurz

on it

#8 Updated by okurz about 4 years ago

  • Status changed from In Progress to Feedback

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

#9 Updated by okurz about 4 years ago

  • Status changed from Feedback to Resolved

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

#10 Updated by okurz about 4 years ago

  • Target version changed from 162 to Milestone 1

Also available in: Atom PDF