QA » openQA Project

Preamble¶

Right now we have 'Interactive Mode', which is effectively an 'Interactive Needling Mode'

This is great, but it does not solve the needs of developers who want to use openQA to reproduce bugs

That is where this proposed 'Interactive Mode' comes in.

User Story¶

As a developer working on a bug reported by openQA I want to log into a SUT for bug reproduction and log gathering to fix the bug

acceptance criteria¶

• a 'breakpoint' can be set over WebUI where the test execution pauses
• the user can log into the SUT remotely when within the same network
• the user can log into the SUT remotely when not in the same network, e.g. o3

tasks¶

• experiment pausing test execution (e.g. does SIGSTOP on the isotovideo process work? maybe the existing interactive mode is good enough?)
• write a guide for non-openQA professionals how to use this to fulfill the user story
• ensure SUTs within the same network can be accessed, e.g. over VNC
• extend access for workers not in the same network
• optional: extend what we use for authentication (see open questions)

further details¶

user story details¶

openQA has found a bug, and that bug has been reported, and the developer wants to reproduce that bug in order to fix it.

The developer wants to have access to the system under test (be it a VM, or a physical machine).
They want to be able to control the keyboard and the mouse.
They may want to be able to extract files from the system (though arguably this can be accomplished by using scp from the system under test in most cases).

In order to accomplish this I believe we need to have a mechanism, in the WebUI, that a Developer can choose a 'breakpoint' for an openQA test

When os-autoinst reaches that module, we want something similar to the 'Interactive Needling Mode', in that the test execution stops

But unlike the Interactive Needling Mode, we want the SUT to keep on running and not be paused.

Okurz suggests something like sending a sigstop to isotovideo might be sufficient here.

The developer would then be able to use the already visible server and port details to connect to the openQA worker instance in question and control the system under test.

This would be sufficient for a Proof of Concept/first phase for this feature, but obviously would not work in situations where the Workers are not directly reachable by the developers reproducing bugs (eg. openqa.opensuse.org)

In this case we would need the webUI server to be able to act as a proxy, and ideally offer the user the VNC in a nice webUI interface, something like https://github.com/kanaka/noVNC. But I consider this 'phase 2' of this feature, with the general 'breakpoints' and 'Proper Interactive Mode' needing to get in place before we worry about making it all Webby for everyone.

implementation suggestions¶

After the interactive session ends the job should probably be aborted, at best with a proper state, e.g. user_cancelled. It's ok for a start to let the job simply fail for any reason, e.g. because it times out itself. In most cases the result of the specific test run used for investigation using remote control is not interesting to us and the system has been tampered with anyway.

open questions¶

• who (e.g. which user group) should be allowed to access the machine?
  • okurz: maybe start with only "Operator" and "Admin" even though it conflicts with the user story mentioning the "developer"
• is someone at fedora interested see #12130#note-1