Project

General

Profile

Actions
Copy link

action #17420

closed

action #13216: [sles][functional][s390x] Run extratest on s390x

[sles][functional][s390x] Test fails in vnc_two_passwords

Added by mkravec about 7 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
High
Assignee:
okurz
Category:
New test
Target version:
-
Start date:
2017-03-02
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Vnc fails to connect, maybe "Xvnc :1 -SecurityTypes=VncAuth -PasswordFile=/tmp/file.passwd" failed to start properly
Test needs some changes to make it more robust (easier to debug)

Observation

openQA test in scenario sle-12-SP3-Server-DVD-s390x-extra_tests_on_gnome_s390x@zkvm fails in
vnc_two_passwords

Reproducible

Fails since (at least) Build 0257 (current job)

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Actions
Copy link
 #1

Updated by mkravec about 7 years ago

  • Assignee changed from mkravec to mgriessmeier
Actions
Copy link
 #2

Updated by mgriessmeier about 7 years ago

  • Subject changed from Test fails in vnc_two_passwords to [sles][functional][s390x] Test fails in vnc_two_passwords
  • Parent task set to #13216
Actions
Copy link
 #3

Updated by mgriessmeier almost 7 years ago

  • Assignee deleted (mgriessmeier)

unassigning, since I did not follow this issue and didn't see it in productive system

Actions
Copy link
 #4

Updated by mkravec almost 7 years ago

  • Status changed from New to Closed

I don't see this test scheduled on s390 anymore, link is not working, please reopen if you see this problem again.

Actions
Copy link
 #5

Updated by okurz almost 7 years ago

  • Description updated (diff)
  • Status changed from Closed to In Progress
  • Assignee set to mkravec
  • Priority changed from Normal to High

With a tiny amount of effort I found the job again. Just the machine changed from "zkvm" to "zkvm-image". And the issue is not gone.

@mkravec A test that "disappeared" should make you wonder and not just accept it. I see it as critical if we silently drop certain test coverage without an explicit decision. This did not happen here, just the machine assignment was changed. The latest failing example for exactly the reason of vnc_two_passwords is seen in https://openqa.suse.de/tests/964105#step/vnc_two_passwords/21
On first sight this looks like a product issue: "No matching security types". Please take a second look.

Actions
Copy link
 #6

Updated by mkravec almost 7 years ago

  • Priority changed from High to Low

@okurz: - .. really? ..

Second look: DISPLAY:1 is busy on s390 - https://openqa.suse.de/tests/964105#step/vnc_two_passwords/22

Actions
Copy link
 #7

Updated by okurz almost 7 years ago

Why do you consider the priority low now? If you don't want to continue the work on this just unassign. If you say we should just not schedule vnc_two_passwords because of low risk we may also do this. We should still conduct the other extra tests on s390x then.

Actions
Copy link
 #8

Updated by mkravec almost 7 years ago

It's low priority because:

  • test is in development group
  • it was never working on s390
  • I created it for x86_64
  • the person who schedules it on s390 should fix / remove the test
  • if it's assigned to me I don't mind, but on my list it's low priority

Please correct me if I am wrong and there is FATE / ISSUE saying otherwise.

When I have time to do local runs I can fix it, if someone want's to do it sooner - feel free to take over.
From error message it should be enough to use other display.

Actions
Copy link
 #9

Updated by okurz almost 7 years ago

  • Category changed from Bugs in existing tests to New test
  • Assignee changed from mkravec to okurz
  • Priority changed from Low to High

IMHO not low prio because this is blocking the full enablement of extra tests on s390x which we should have in place for sle15 at least which will probably rely much more on pre-generated installations. But you are right that it never worked so I changing it to "New test" now. As mentioned and as discussed, maybe we can just change the display port number for the vnc server to fix it. I will try the first step myself. If I read the error message correctly what the test is doing is to connect to the hardcoded display number assuming it is the vnc server it started itself but in this case it will be the internal VNC server in the SUT we use to interface with the SUT.

-> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3342

Actions
Copy link
 #10

Updated by okurz almost 7 years ago

  • Status changed from In Progress to Resolved

merged, https://openqa.suse.de/tests/1078008# passed this step in production now.

Actions
Copy link

Also available in: Atom PDF