Project

General

Profile

Actions
Copy link

action #117100

closed

coordination #121876: [epic] Handle openQA review failures in Yam squad - SLE 15 SP5

Adjust bootloader_start on s390x to new YaST start message

Added by rainerkoenig over 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
shukui
Target version:
Current
Start date:
2022-09-23
Due date:
% Done:

0%

Estimated time:

Description

Observation

With Build 24.1 we get a systematic failure in bootloader_start on S390x (kvm and zvm):

Example: https://openqa.suse.de/tests/9563755#step/bootloader_start/37

First line in the output says

# wait_serial expected: " Starting YaST2 "

but at the end when YaST starts the message is:

*** Starting YaST ***

Fix should be easy by adjusting the trigger text.

Acceptance criteria

AC1: Trigger text is adjusted, tests no longer fail in bootloader_start
AC2: Adjusted code doesn't break other products (apparently this change is only in SLE-15-SP5)

Additional info

YaST team told us, that the YaST startup message intentionally changed because of this commit:
https://github.com/yast/yast-installation/commit/462733aca602bb2cf9eb8f309b9c58620b7f2938

wait_serial takes regex as parameter, favor that solution over if/else statements in code.

Actions
Copy link
 #1

Updated by rainerkoenig over 2 years ago

  • Description updated (diff)
  • Priority changed from Normal to High
Actions
Copy link
 #2

Updated by JERiveraMoya over 2 years ago

  • Tags set to qe-yast-refinement
  • Description updated (diff)
  • Target version set to Current
Actions
Copy link
 #3

Updated by coolgw over 2 years ago

checked.
s/YaST2/YaST/ if sle=15sp5

Actions
Copy link
 #4

Updated by rainerkoenig over 2 years ago

Would we lose much "precision" if we just do a

s/YaST2/YaST/

without checking for any specific version? Those checks always open the door to problems if new versions arrive.

Actions
Copy link
 #5

Updated by JERiveraMoya over 2 years ago

coolgw wrote:

checked.
s/YaST2/YaST/ if sle=15sp5

that is why I added 'favor the solution without conditions' :)

Actions
Copy link
 #6

Updated by JERiveraMoya over 2 years ago

rainerkoenig wrote:

Would we lose much "precision" if we just do a

s/YaST2/YaST/

without checking for any specific version? Those checks always open the door to problems if new versions arrive.

It makes sense, but there are some spaces that perhaps needs to be accounted..." YaST " we'll see.

Actions
Copy link
 #7

Updated by JERiveraMoya over 2 years ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable
Actions
Copy link
 #8

Updated by shukui over 2 years ago

  • Assignee set to shukui
Actions
Copy link
 #9

Updated by shukui over 2 years ago

  • Status changed from Workable to In Progress
Actions
Copy link
 #11

Updated by shukui over 2 years ago

  • Status changed from In Progress to Resolved
Actions
Copy link
 #12

Updated by openqa_review over 2 years ago

  • Status changed from Resolved to Feedback

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_zvm_sles_product_reg@s390x-zVM-vswitch-l2
https://openqa.suse.de/tests/9919870#step/bootloader_start/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions
Copy link
 #13

Updated by JERiveraMoya over 2 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #14

Updated by JERiveraMoya about 2 years ago

  • Parent task set to #121876
Actions
Copy link

Also available in: Atom PDF