action #60758
open
better feedback for Xvnc disconnecting clients, integration tests covering Xvnc in travis CI as well or OBS
Added by okurz almost 5 years ago.
Updated over 4 years ago.
Category:
Feature requests
Description
Motivation¶
As a test reviewer of tests running on remote backends I do not want to be lost what is the source of the problem when the only thing I see is error messages from xterm.
Also see #60539 . Xvnc is used in more and more tests where we connect to a remote hypervisor to run VMs on and establish connections between the VM, the hypervisor and the openQA worker instance. The feedback in case of failures can be improved and we do not have this setup covered in os-autoinst tests so making changes is risky.
Suggestions¶
- Create tests using any Xvnc based backend, not qemu, which at least start up the complete stack and ensure it being able to execute tests, e.g. only simulate a VM, just work with the xterm-console that is started
- Copied from action #60539: openQA remote-back-ends crashes with Xvnc >= 1.9.80 added
Xvnc did not crash, but disconnect us as if we were a bad client. And only the version of tumbleweed did - so any test coverage on 15.1 would have been green. So what's the user story of this feature?
- Status changed from New to Rejected
And it only disconnected us after certain things happened on the screen - so this is really just asking to waste time. I'm rejecting
- Subject changed from better feedback for Xvnc crashing, integration tests covering Xvnc in travis CI as well or OBS to better feedback for Xvnc disconnecting clients, integration tests covering Xvnc in travis CI as well or OBS
- Description updated (diff)
- Status changed from Rejected to New
I also think there's room for improvement:
- Having a better test environment for Xvnc and our VNC client seems useful - even if it is just a script to ease manual testing like the one @coolo mentioned in the chat.
- It is annoying that the use of
-inetd prevents Xvnc error messages to be logged. Maybe there's an easy way to improve this (e.g. writing to a log file).
Xvnc clearly documents no errors with -inetd - but unix domain socket is another option to avoid the tcp port problem.
- Target version set to future
Also available in: Atom
PDF