action #39815: [functional][y] logs_from_installation_system always shows a red border but we do not track it as a bug - openQA Tests - openSUSE Project Management Tool

Custom queries

All open Feature tests
openQA Infrastructure Project
openqa-review - Closed tickets last updated by openqa-review, last 30 days
QA roadmap long-term
QA SLE functional
QA SLE Functional - closed in last 14 days
QA SLE Functional - High, need to be refined
QA SLE Functional - over cycle time median
QA SLE u
QA SLE y
QA tools (tag not necessary in openQA and subprojects)
QA tools tag (tag not necessary in openQA and subprojects; excluding tickets in "Ready" version as they are already on the backlog)
QAC - Backlog
QAM
QE tools team - backlog (ready issues)
QE tools team - backlog (w/o infra)
QE tools team - backlog SLA high
QE tools team - backlog SLA immediate
QE tools team - backlog SLA no immediate/urgent in feedback/blocked
QE tools team - backlog SLA normal
QE tools team - backlog SLA urgent
QE tools team - backlog SLO high
QE tools team - backlog SLO normal
QE tools team - backlog SLO urgent
QE tools team - backlog, high-level view (epics and higher)
QE tools team - backlog, non-reactive work, needs parent
QE tools team - backlog, top-level view (all sagas)
QE tools team - closed within last 14 days
QE tools team - closed within last 60 days
QE tools team - closed yesterday
QE Tools Team - Collaborative Session
QE tools team - due date forecast
QE tools team - exceeding due-date
QE tools team - infrastructure backlog
QE tools team - next - sorted by update time
QE tools team - next issues
QE tools team - non-estimated (unblocked) issues (w/o infra)
QE tools team - ready issues - Workable
QE tools team - ready, not assigned/blocked/low
QE tools team - update forecast
QE tools team - updated by priority
QE tools team - what members of the team are working on - Feedback (not-low)
QE Tools Team Backlog By Assignee
SLE15 Migration Open Tickets
SLE15 SP1 Migration Open Tickets
SLE15SP3 Migration open ticket
SLE15SP3 Security open ticket
Tools Team Retrospective
Tools Team Retrospective (not estimated or assigned)

Actions

Copy link

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 5 years ago. Updated about 5 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

riafarov

Category:

Enhancement to existing tests

Target version:

SUSE QA - Milestone 23

Start date:

2018-03-13

Due date:

2019-03-12

% Done:

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 open — 2 closed)

Blocks openQA Tests - action #37592: [functional][y] Record soft-failure for detected errors in logs

Resolved

riafarov

2018-06-21

2019-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 border

Resolved

dheidler

2018-03-13

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

Updated by okurz over 5 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

Copy link

Updated by okurz over 5 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

Copy link

Updated by okurz over 5 years ago

Target version set to Milestone 20

Actions

Copy link

Updated by okurz over 5 years ago

Target version changed from Milestone 20 to Milestone 21

Actions

Copy link

Updated by okurz over 5 years ago

Target version changed from Milestone 21 to Milestone 22

Actions

Copy link

Updated by okurz over 5 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

Copy link

Updated by okurz over 5 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

Copy link

Updated by okurz over 5 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

Copy link

Updated by okurz over 5 years ago

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

Actions

Copy link

#10

Updated by riafarov over 5 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

Copy link

#11

Updated by riafarov over 5 years ago

Description updated (diff)

Actions

Copy link

#12

Updated by JERiveraMoya about 5 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

Copy link

#13

Updated by riafarov about 5 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

Copy link

#14

Updated by oorlov about 5 years ago

Assignee set to oorlov

Actions

Copy link

#15

Updated by oorlov about 5 years ago

Status changed from Workable to In Progress

Actions

Copy link

#16

Updated by oorlov about 5 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

Copy link

#17

Updated by oorlov about 5 years ago

File y2logs_errors.ods y2logs_errors.ods added

Actions

Copy link

#18

Updated by riafarov about 5 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

Copy link

#19

Updated by okurz about 5 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

Copy link

#20