Home Home > Tag > openqa
Sign up | Login

Posts Tagged ‘openqa’

Highlights of YaST Development Sprint 85

September 26th, 2019 by

Refactored Network on its way to Tumbleweed

A few weeks ago we submitted the first round of changes to the network module to Tumbleweed. At that point, it was still using the old data model for most operations (except routing and DNS handling) and a lot of work remained to be done.

We have been working hard on improving the overall quality of this module and we will submit an updated (and much improved) version in the upcoming days. To summarize, here are some highlights:

  • Completed the new data model (support for TUN/TAP, bridges, bonding, VLANs, etc.).
  • New wireless configuration workflow.
  • Revamped support for interface renaming and driver assignment, including better udev rule handling.
  • Fixed /etc/hosts handling when switching from static to DHCP based configuration.
  • Many small fixes in several areas.

Are we done with the refactoring? No, we are still working on improving S390 support and fixing small issues, but most of the work is already done.

Of course, as soon as we finish, we will publish a blog entry with the gory details. But, as we know that you love screenshots, let us show you a handful of them.

Although we have not introduced big user interface changes, we have tried to improve small things, like properly displaying whether an interface belongs to a VLAN or hiding the "Hardware" tab for virtual interfaces.

DNS resolution not working during installation, or: openQA is different

When we got a bug report that DNS resolution was not working during installation (since SLE-15 apparently), a solution seemed straightforward: /run/netconfig/resolv.conf was missing because the /run directory was not mirrored (bind-mounted) into the target system. That’s a task that used to be done by yast-storage in times before SLE-15 and was for some unknown reason forgotten when we implemented yast-storage-ng. A one-line fix was easily done, tested, and submitted.

Or so it seemed.

A few days later we got reports from SLE openQA that tests started to fail with this patch. Nothing networking related but the installation did not finish because the 10 seconds countdown dialog (‘going to reboot’) at the very end of the installation was frozen. The UI didn’t accept any input whatsoever. But whatever we tried, the issue was not reproducible outside openQA. YaST logs from openQA showed that /run got mounted as planned and was cleanly unmounted at the end of the installation – before that frozen dialog. So no clue so far and the issue was set aside for a while. Until the same reports came in from Tumbleweed testing. It was clearly linked to this one-line patch. But how?

It stayed a mystery until a chat with an openQA expert shed some light on the issue. What we thought was happening was: openQA stopped the dialog (by pressing a button) and when it tried to go on the OK button did not respond anymore. What we learned does actually happen is this: openQA stops the dialog, then switches from X to the text console, collects logs, switches back to X, and then the UI does not respond anymore. So that was quite an essential point missing.

And with this it was easily reproduced outside openQA: the X logs showed that the X server lost all its input devices after the switch. And that was because someone had deleted the whole /run directory. The YaST logs didn’t contain a hint (of course not, would have been too easy) but grepping the sources found the place where YaST deleted the directory.

The code had been added after complaints that the installation left a cluttered /run directory – of course the installation did leave files there, since it was forgotten to bind-mount the directory. So once the mentioned patch bind-mounted it again the deletion code cleaned up not /run in the installation target system but the real /run as well – cutting off the X server from the outside world resulting in freezing the openQA test.

And the moral of the story is: probably none. But it highlights again that the automated test setup can have unexpected feedback on the test itself. Luckily in this case, as the issue would not have been noticed otherwise.

Computer, Enlarge the Device Graph

The partitioner module has a graphical view to help you see the relations in more complex storage setups:

If you turn the mouse scroll wheel up or down, we will zoom the view in or out. Now the direction matches the behavior in web browsers and online maps, previously we had it the wrong way around.

Update: during proofreading, a team mate told me: "A device graph? That’s not a device graph. THAT’s a device graph:"

What happened @ FOSSCOMM 2015, Athens Nov 6-8

November 12th, 2015 by

DSC_0746

The 8th Free and Open Source Software Communities Meeting (FOSSCOMM) took place in Athens (Greece), November 6-8th 2015 at the Technical Educational Institute of Athens.

The Conference started early on Saturday morning welcoming the participants and with the key note. Various presentations about open source software, hardware constructions and some workshops took place. Presentations such as Raspberry Pi arcade, openstack, OSGeo, ownCloud, Bitcoin and many more were quite interested by the visitors.

DSC_0716

Greek openSUSE community was there with a booth and some presentations. On Saturday Alex P. Natsios presented “Enlightment on openSUSE”, an alternative GUI, and the other presentation was about “openQA”. Since openSUSE Leap 42.1 was very fresh, Alexandros Vennos took the opportunity to present what are openSUSE Leap 42.1 and Tumbleweed, the differences and what to install on what occasions. Presentation had title “openSUSE – Leaping Ahead”.

DSC_0709

The booth was quite crowded. We had some left over DVDs of 13.2 but we proposed the visitors to install Leap 42.1. The question we were asked most was what is the difference between openSUSE Leap and Tubleweed and why to install and on what ocasion. We even created couple of bootable USBs from the ISOs of Leap. We had a Banana Pi running Tumbleweed with MATE playing a video loop of openSUSE Leap 42.1 KDE review. We gave almost all of our promo materials to the visitors since they were interested on openSUSE.

For more pictures check Flickr

DSC_0736

another way to access a cloud VM’s VNC console

February 8th, 2014 by

If you have used a cloud, that was based on OpenStack, you will have seen the dashboard including a web-based VNC access using noVNC + WebSockets.
However, it was not possible to access this VNC directly (e.g. with my favourite gvncviewer from the gtk-vnc-tools package), because the actual compute nodes are hidden and accessing them would circumvent authentication, too.

I want this for the option to add an OpenStack-backend to openQA, my OS-autotesting framework, which emulates a user by using a few primitives: grabbing screenshots and typing keys (can be done through VNC), powering up a machine(=nova boot), inserting/ejecting an installation medium (=nova volume-attach / volume-detach).

To allow for this, I wrote a small perl script, that translates a TCP-connection into a WebSocket-connection.
It is installed like this
git clone https://github.com/bmwiedemann/connectionproxy.git
sudo /sbin/OneClickInstallUI http://multiymp.zq1.de/perl-Protocol-WebSocket?base=http://download.opensuse.org/repositories/devel:languages:perl

and is used like this
nova get-vnc-console $YOURINSTANCE novnc
perl wsconnectionproxy.pl --port 5942 --to http://cloud.example.com:6080/vnc_auto.html?token=73a3e035-cc28-49b4-9013-a9692671788e
gvncviewer localhost:42

I hope this neat code will be useful for other people and tasks as well and wish you a lot of fun with it.

Some technical details:

  • The code is able to handle multiple connections in a single thread using select.
  • HTTPS is not supported in the code, but likely could be done with stunnel.
  • WebSocket-code was written in 3h.
  • noVNC tokens expire after a few minutes.