Project

General

Profile

Actions

action #39815

closed

[functional][y] logs_from_installation_system always shows a red border but we do not track it as a bug

Added by okurz over 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Enhancement to existing tests
Target version:
SUSE QA - Milestone 23
Start date:
2018-03-13
Due date:
2019-03-12
% Done:

0%

Estimated time:
3.00 h
Difficulty:

Description

Motivation

https://openqa.suse.de/tests/1946720#step/logs_from_installation_system/23 shows a red border because we seem to have always "error messages" in y2log . This is known already by the yast team and they want to work on it, e.g. see https://bugzilla.suse.com/show_bug.cgi?id=1088172 and https://trello.com/c/fVgXwqaZ/2224-sles15-p4-1088172-many-error-messages-in-y2log-eg-about-lib-cheetahrb206-error-output-installing-for-arm64-efi-platform-because
so we should rather track as that bug with a soft-fail

Acceptance criteria

  • AC1 No red border in general for known, accepted behavior (optional)

Suggestions

  • Try to turn the existing red border into a soft-fail referencing the above mentioned bug but still provide the log output in a text window
  • Still show a red border for the other steps, e.g. the "likely error" and such

Further details

Always latest result in this scenario: latest
soft-failing will be addressed with #45470


Files

y2logs_errors.ods (20.3 KB) y2logs_errors.ods oorlov, 2019-02-01 12:40

Related issues 2 (0 open2 closed)

Blocks openQA Tests - action #37592: [functional][y] Record soft-failure for detected errors in logsResolvedriafarov2018-06-212019-03-12

Actions
Copied from openQA Tests - action #39809: [functional][u][s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red borderResolveddheidler2018-03-13

Actions
Actions #1

Updated by okurz over 6 years ago

  • Copied from action #39809: [functional][u][s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border added
Actions #2

Updated by okurz over 6 years ago

  • Subject changed from [functional][y] logs_from_installation_system always shows a red border but we do not track it as a bug to [functional][y][epic] logs_from_installation_system always shows a red border but we do not track it as a bug
  • Due date deleted (2018-09-11)
  • Difficulty deleted (easy)

We agreed that the idea in general is ok but we do not want to hide all generic error output under one record_soft_failure so we should try to look for a more flexible approach to track individual known or unknown issues in the log.

TODO: there should be another ticket with a request by the yast-team to look for one specific "translations missing" log message and explicitly fail the test, link it here

Actions #3

Updated by okurz over 6 years ago

  • Target version set to Milestone 20
Actions #4

Updated by okurz almost 6 years ago

  • Target version changed from Milestone 20 to Milestone 21
Actions #5

Updated by okurz almost 6 years ago

  • Target version changed from Milestone 21 to Milestone 22
Actions #6

Updated by okurz almost 6 years ago

  • Due date set to 2019-02-12

pre-fill last sprint in M22 with all tickets within milestone not yet assigned to sprints

Actions #7

Updated by okurz almost 6 years ago

  • Status changed from New to Workable

I think we can now move forward given that lately we have also added more specific log parsing rules for the YaST logs, e.g. as in 61ed7de49 where we now also look for "Couldn't load pixmap" which also the YaST development team appreciates (I think).

Actions #8

Updated by okurz almost 6 years ago

  • Subject changed from [functional][y][epic] logs_from_installation_system always shows a red border but we do not track it as a bug to [functional][y] logs_from_installation_system always shows a red border but we do not track it as a bug
Actions #9

Updated by okurz almost 6 years ago

  • Blocks action #37592: [functional][y] Record soft-failure for detected errors in logs added
Actions #10

Updated by riafarov almost 6 years ago

  • Description updated (diff)

I don't see how is that any problem or priority, changed description to include main part we agreed on to actually detect new issues as https://openqa.suse.de/tests/2386090 constantly fails.

Actions #11

Updated by riafarov almost 6 years ago

  • Description updated (diff)
Actions #12

Updated by JERiveraMoya almost 6 years ago

What would be the difference with #45470. In the record_soft_failure we can also display details -> Check verification in PR. Perhaps I'm missing something else ...

Actions #13

Updated by riafarov almost 6 years ago

  • Estimated time set to 3.00 h

After #45470, we need to file bugs for current errors when installation works fine starting with and change code to map those to created bugs.

Actions #14

Updated by oorlov almost 6 years ago

  • Assignee set to oorlov
Actions #15

Updated by oorlov almost 6 years ago

  • Status changed from Workable to In Progress
Actions #16

Updated by oorlov almost 6 years ago

After discussion with Ancor Gonzales Sosa, it was decided that I'll send the list of the errors to the YaST team and they will assist us to identify of which of the issues should be addressed with bugzilla tickets and which ones are not.

I've created a list and sent it. Please, see its copy in the attached 'y2logs_errors.ods' file.

So, currently I'm waiting for the feedback from them.

Actions #18

Updated by riafarov almost 6 years ago

  • Due date changed from 2019-02-12 to 2019-02-26
  • Status changed from In Progress to Blocked

Alex will ask again over e-mail. riafarov will support to make it happen.

Actions #19

Updated by okurz almost 6 years ago

  • Status changed from Blocked to Feedback
  • Target version changed from Milestone 22 to Milestone 23

I suggest to not use "Blocked" because others would have a hard time to see if oorlov has received an email already. My suggestion to do e.g. at the end of next week is to report a bug for each issue and point the soft-fail to each issue. Then we have clear documentation within the bug report when we in cooperation with developers decide for which issue to not track further as bug and such.

Actions #20

Updated by riafarov over 5 years ago

  • Due date changed from 2019-02-26 to 2019-03-12

riafarov will communicate with Lukas to clarify how to proceed with it (e.g. single bug, or multiple ones).

Actions #21

Updated by riafarov over 5 years ago

  • Assignee changed from oorlov to riafarov

Will address along with #48137.

Actions #24

Updated by riafarov over 5 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF