Today OpenQA mostly runs on virtual machines, but it can get really tricky to find bugs triggered by real hardware. There are only few interfaces required to interact with a machine though:
1) HDMI
2) USB keyboard
3) CD-ROM
4) Remote Power Switching
For 1, I ordered a few HDMI frame grabbers that will only arrive after Hackweek. 2 and 3 should be possible to implement using the USB gadget support in Linux which a lot of ARM devices support - I can definitely donate a Beaglebone Black to whoever is interested. Power switching is a solved problem.
With all these bits in place and a bit of plumbing we should be able to run tests on actual hardware, hopefully extending our test coverage to more tricky scenarios.
Succeeded in emulating USB-mass-storage and USB-keyboard and serial. Also made a RPC for it, so you can use it in code running on any machine. See the demo video
Code is in a github branch
This allows to boot any machine off a virtual USB-CDROM and automate with keystrokes.
Still to do: emulate a tablet with absolute pointer coordinates and capture screen output.
This project is part of:
Hack Week 12
Activity
Comments
-
about 10 years ago by ancorgs | Reply
I guess you are aware of the IPMI and KVM2USB openQA backends and the discussions about real hardware support in the openQA mailing list (sorry, I don't know where to find the archives) that leaded to try IPMI as a first approach.
-
-
about 10 years ago by algraf | Reply
I just realized that we don't need to jump through hoops with the stm32 board or other cruftyness but instead we can just use the USB gadget support in Linux! So I guess the big task here would be to write a driver for the frame grabber, but that one will still take a few weeks to arrive :(.
That means for now, the main goal of this project would be to script up working USB hid and mass storage emulation by leveraging the already existing Linux infrastructure. Then add some plumbing to hook it up into OpenQA. Then wait until the hdmi grabber arrives ;).
-
-
about 10 years ago by bmwiedemann | Reply
Btw: from my experience with the kvm2usb, most hardware-specific bugs found are in the graphics drivers (apart from things like having 2 ethernet-ports with one being unconnected, which can be emulated in KVM)
-
Similar Projects
OpenQA Golang api client by hilchev
Description
I would like to make a simple cli tool to communicate with the OpenQA API
Goals
- OpenQA has a ton of information that is hard to get via the UI. A tool like this would make my life easier :)
- Would potentially make it easier in the future to make UI changes without Perl.
- Improve my Golang skills
Resources
- https://go.dev/doc/
- https://openqa.opensuse.org/api
New features in openqa-trigger-from-obs for openQA by jlausuch
Description
Implement new features in openqa-trigger-from-obs to make xml more flexible.
Goals
One of the features to be implemented: - Possibility to define "VERSION" and "ARCH" variables per flavor instead of global.
Resources
https://github.com/os-autoinst/openqa-trigger-from-obs
Setup a new openQA on more powerful server by JNa
Description
- currently local openQA storage is insufficient
Goals
-Migrate to more powerful machine
Resources
-Service Rainbow
Learn obs/ibs sync tool by xlai
Description
Once images/repo are built from IBS/OBS, there is a tool to sync the image from IBS/OBS to openqa asset directory and trigger openqa jobs accordingly.
Goals
Check how the tool is implemented, and be capable to add/modify our needed images/repo in future by ourselves.
Resources
- https://github.com/os-autoinst/openqa-trigger-from-obs
- https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/tree/master?ref_type=heads
Hack on isotest-ng - a rust port of isotovideo (os-autoinst aka testrunner of openQA) by szarate
Description
Some time ago, I managed to convince ByteOtter to hack something that resembles isotovideo but in Rust, not because I believe that Perl is dead, but more because there are certain limitations in the perl code (how it was written), and its always hard to add new functionalities when they are about implementing a new backend, or fixing bugs (Along with people complaining that Perl is dead, and that they don't like it)
In reality, I wanted to see if this could be done, and ByteOtter proved that it could be, while doing an amazing job at hacking a vnc console, and helping me understand better what RuPerl needs to work.
I plan to keep working on this for the next few years, and while I don't aim for feature completion or replacing isotovideo tih isotest-ng (name in progress), I do plan to be able to use it on a daily basis, using specialized tooling with interfaces, instead of reimplementing everything in the backend
Todo
- Add
maketargets for testability, e.g "spawn qemu and type" - Add image search matching algorithm
- Add a Null test distribution provider
- Add a Perl Test Distribution Provider
- Fix unittests https://github.com/os-autoinst/isotest-ng/issues/5
- Research OpenTofu how to add new hypervisors/baremetal to OpenTofu
- Add an interface to openQA cli
Goals
- Implement at least one of the above, prepare proposals for GSoC
- Boot a system via it's BMC
Resources
See https://github.com/os-autoinst/isotest-ng