Project

General

Profile

Actions

action #39809

closed

[functional][u][s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border

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

Status:
Resolved
Priority:
Low
Assignee:
Category:
Enhancement to existing tests
Target version:
Start date:
2018-03-13
Due date:
% Done:

0%

Estimated time:
Difficulty:
easy

Description

Observation

https://openqa.suse.de/tests/1946861#step/boot_to_desktop/16 shows https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5319 in action with a red border around the first connection check when the SUT is not yet reachable.

Acceptance criteria

  • AC1 No red border when afterwards everything works fine
  • AC2 Still obvious notice in case the connection can never be established

Suggestions

The ideal case would be to use a grey color which is neutral.
A workaround would be to use the blue color, but not using the wording "soft-fail".

Use same approach as mgriessmeier used in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5319#issuecomment-409203353 to show a blue border seems to be a good choice

Further details

Always latest result in this scenario: latest


Related issues 2 (0 open2 closed)

Copied from openQA Tests (public) - action #33202: [sle][functional][s390x][zkvm][u][hard] test fails in boot_to_desktop - still insufficient error reporting, black screen with mouse cursor - we all hate it (was: I hate it)Resolvedmgriessmeier2018-03-132018-08-14

Actions
Copied to openQA Tests (public) - action #39815: [functional][y] logs_from_installation_system always shows a red border but we do not track it as a bugResolvedriafarov2018-03-132019-03-12

Actions
Actions #1

Updated by okurz over 6 years ago

  • Copied from action #33202: [sle][functional][s390x][zkvm][u][hard] test fails in boot_to_desktop - still insufficient error reporting, black screen with mouse cursor - we all hate it (was: I hate it) added
Actions #2

Updated by okurz over 6 years ago

  • Estimated time deleted (13.00 h)
Actions #3

Updated by okurz over 6 years ago

  • Copied to action #39815: [functional][y] logs_from_installation_system always shows a red border but we do not track it as a bug added
Actions #4

Updated by SLindoMansilla over 6 years ago

  • Description updated (diff)
Actions #5

Updated by SLindoMansilla over 6 years ago

  • Description updated (diff)
  • Assignee set to okurz
  • Priority changed from Normal to Low
Actions #6

Updated by okurz over 6 years ago

  • Subject changed from [functional][s390x][u] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border to [functional][s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border
  • Due date deleted (2018-09-11)
  • Target version set to future

As discussed with the team, QSF is not convinced in doing that. I am fine with that so let's work on it as a side-project, e.g. outside work hours :)

Actions #7

Updated by okurz about 6 years ago

  • Subject changed from [functional][s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border to [s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border
Actions #8

Updated by okurz almost 6 years ago

  • Status changed from New to Blocked

-> #39815

Actions #9

Updated by okurz almost 6 years ago

  • Subject changed from [s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border to [functional][u][s390x] ssh connection check shows red border misleading that something is wrong when there is not -> should be no red border
  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)

We can look into this again, #39815 resolved

Actions #10

Updated by dheidler over 5 years ago

  • Status changed from Workable to Resolved
  • Assignee set to dheidler

This seems to be already fixed as of https://openqa.suse.de/tests/2314767

Actions

Also available in: Atom PDF