Über unsMediaKontaktImpressum
Markus Feilner 14. Juli 2015

Distributionen testen mit openQA

"The Maker's Choice" – unter diesem neuen Schlagwort will sich das openSUSE-Projekt [1] selbst neu erfinden. Bei der grünen Community-Distribution hat sich einiges getan in den letzten Jahren, vor allem in Sachen Infrastruktur. Die Stichworte lauten SUSE Studio, Open Build Service, KIWI, openQA, Tumbleweed und SUSE Factory – und aus dem Zusammenspiel dieser von der SUSE-Community initiierten Projekte ergibt sich gerade eine völlig neue Ausrichtung der freien Linux-Distribution. "openSUSE is so much more than just a distribution" erklärte Board-Member Richard Brown in seiner Keynote "The Future is unwritten" auf der Entwicklerkonferenz openSUSE Conference 2015 in Den Haag [2].

Tumbleweed

openSUSE setze verstärkt auf Tumbleweed [3] – das Rolling Release der beliebten Distribution – und das liege auch daran, dass die auf mittlerweile durchschnittlich 12.000 Benutzer angewachsene Nutzerschar erkannt habe, dass diese Version die am besten getestete SUSE-Variante sei. Das, so Brown, sei nur möglich durch die Tools im Hintergrund. Die openSUSE-Community hat sich ein Ökosystem geschaffen, welches das Bauen und Testen einer Linux-Distribution weitgehend automatisiert, so dass die Entwickler sich auf das konzentrieren können, was ihnen am meisten Spaß macht: Neue Features entwickeln – und natürlich Bugs fixen.

Open Build Service

An erster Stelle im Ökosystem steht da der vielgelobte openSUSE Build Service [4], der heute einfach Open Build Service oder kurz OBS genannt wird. Dieser Cluster aus mehreren hundert Cores baut automatisch Binärpakete aus Quelltextarchiven, die die Entwickler hinaufladen. Neben SUSEs eigener Buildfarm arbeiten hier zwischen 400 und 800 Rechnerkerne, gesponsort von SUSE und Partnern, frei verwendbar für Community und Entwickler im Web. Keines dieser Tools ist auf SUSE oder openSUSE beschränkt – man versteht es vielmehr als Service für freie Linux-Entwickler, und deshalb lassen sich mit dem OBS eben auch Ubuntu, oder sogar Red-Hat-, Debian- oder Mandrive-Pakete bauen. Der große Vorteil für Developer ist: Sie brauchen sich keine Gedanken mehr um ihre Build-Systeme zu machen, all das übernimmt der OBS. "Wirf Deinen Quellcode vorne rein, dann kommen hinten die Pakete für zahllose Architekturen und Distributionen raus" lautet das Versprechen.

SUSE Studio

Eine komplette Distribution besteht in der Regel aus zahllosen binären Softwarepaketen. Die Auswahl dieser Pakete (vom Entwickler selbst oder von anderen, beispielsweise im OBS entwickelt und veröffentlicht) obliegt normalerweise dem Distributor, doch in Zeiten des Cloud-Computing oder generell von verbreiteter Virtualisierung wuchs das Interesse an maßgeschneiderten ISO-Images für einzelne Anwendungen. Man nehme Pakete von Serverdiensten, kombiniere sie mit allen notwendigen Libraries und ein paar netten Tools, baue daraus ein ISO-Image und schon hat man ein maßgeschneidertes Image für die eigene Cloud. Genau dabei hilft SUSE Studio.

Ein Distributor wie openSUSE muss diese Schritte naturgemäß sehr häufig machen, und deshalb etablierte die Community auch hierfür eine automatisierte Lösung: SUSE Studio erledigt den Bau von ISO-Images (oder auch VMware- oder andere Virtualisierungsabbilder) über ein schickes Webinterface, per Mausklick und auf Wunsch vollautomatisch. Im Hintergrund werkelt der Image-Builder KIWI [5], SUSE Studio ist "nur" ein Ruby-on-Rails-basiertes Webinterface für KIWI.

Free to use: Studio

Auch Studio steht der Öffentlichkeit zur Verfügung, Anwender können Images bauen, uploaden, zum Download bereitstellen und verändern. Fans von Owncloud, KDE, GNOME oder die Firmen hinter diversen Open-Source- oder auch proprietärer Software nutzen den Dienst, um ihre Lieblingssoftware oder ihre Produkte unter die Leute zu bringen. Aktuell supportet Studio KVM, Virtual Box, VMWare und besagte ISO-Images. Wer mag, klickt sich seine eigene Variante zusammen, indem er auf einem Image aufbaut oder mit openSUSE, SLES oder JeOS beginnt.

Sowohl Studio als auch der Build Service gewannen stark an Bedeutung, als das Rolling Release Tumbleweed [3] mehr und mehr zentraler Bestandteil der openSUSE-Entwicklung wurde. Ende 2014 entschieden die Entwickler, den Development-Tree Factory mit dem Rolling Release zu verschmelzen. Schon openSUSE 13.2 war dann nur mehr ein Snapshot von Tumbleweed, der als Version 13.2 veröffentlicht wurde. Tumbleweed ist die Basis für alle Entwicklungen in openSUSE heute, gleichzeitig aber auch das Test-Bed für Entwickler.

High-Speed-Entwicklung

Das bedingt aber auch eine sehr hohe Entwicklungsgeschwindigkeit – was ursprünglich auch zu der neuen Strategie führte: Zwei neue Versionen pro Jahr entsprachen schlicht nicht mehr der immer schneller fortschreitenden Erneuerung innerhalb der Communitydistribution. Tumbleweed bringt heute teilweise mehrere Versionen pro Tag auf den Downloadserver, alle aus dem oben beschriebenen Workflow automatisch generiert und getriggert von Veränderungen im Sourcecode und durch Maintainer, die Pakete updaten. Diese täglichen Snapshots könnte man eigentlich nicht auf die Community loslassen, würden sie nicht ausgiebig getestet – und hier kommt die vollautomatische Testsuite openQA ins Spiel.

openQA

Aus dem oben beschriebenen Workflow fallen täglich ISO-Images an, die den aktuellen Stand von openSUSE Tumbleweed wiedergeben. Taucht ein solches ISO-Image auf, stürzt sich voll automatisch ein (oder mehrere) Worker von openQA darauf und testet die Funktionalität, also beispielsweise ob die Distribution sauber installiert.

openQA fungiert dabei als Test-Tool zur Qualitätssicherung (Quality Assurance, QA), hilft aber auch bei Themen der Continuous Integration (CI) und Versionskontrolle. Startet ein Build nicht, können die Entwickler und QA-Tester genau nachvollziehen, was wann und warum geändert wurde und den Fehler auslöste. Wie Abb.5 zeigt, schwankt dementsprechend auch die Qualität der Snapshots, ein natürlicher Prozess in Entwicklungsumgebungen.

Das Leben ist zu kurz für manuelle Tests!

openQA entstand eigentlich aus der für Entwickler nervigen Situation, dass jede Form der Qualtitätssicherung zahlreiche, gleiche, immer wiederkehrende Schritte verlangt. Das zu automatisieren lag nahe, und es scheint sehr gut gelungen zu sein: Immerhin gab auch SUSE mittlerweile bekannt, den Quelltext seines Enterprise Servers in der openSUSE-Toolchain freizugeben und mit openQA zu testen [6]. Wie das Projekt heißen soll, darüber streiten sich die Entwickler noch beherzt, aber der Weg ist klar: Für die kommenden, "festen" openSUSE-Releases mit Versionssnummern soll SLES die Basis sein und so Power-User addressieren, denen weniger an topaktueller, aber eventuell instabiler Software liegt. Das "Projekt ohne Namen" will so die auf Stabilität und Zuverlässigkeit bedachten openSUSE-Anwender bedienen. Details dazu bietet Richard Browns Keynote [3] .

Wie funktioniert openQA?

openQA wendet einige der grundlegendsten UNIX-Dogmas konsequent an: "Keep it simple, one tool for one Job". Taucht ein neues ISO-Image im Arbeitsverzeichnis auf, so startet openQA einfach einen Worker, der wiederum eine KVM-Instanz bootet, in der das neue ISO-Image als Boot-Medium dient. Davon gibt es Screenshots und Videos auf der Webseite, die das Nachvollziehen von Fehlern stark vereinfachen.

Weil das Booten oder gar die Installation einer Linux-Distribution Eingaben erfordert und zwar schon auf dem ersten Bildschirm (im Bootmanager), mussten sich die Entwickler etwas einfallen lassen. Glücklicherweise bringt KVM bereits (fast) alles mit, was man dafür benötigt: Einen VNC-Server und eine API für die Eingabe von Tastaturbefehlen und Mausevents.

Was jetzt noch fehlt ist die Erfolgskontrolle und geeignete Tests. openQA nimmt mehrmals pro Sekunde einen Screenshot der virtuellen Maschine auf. Die Entwickler wiederum haben derartige Bildschirmschnappschüsse vorbereitet, die das Wunschergebnis wiedergeben. Und OpenCV (Open Computer Vision) [15], eine Bibliothek zur befehlszeilenbasierten Bildverarbeitung, übernimmt das Vergleichen. Um die Erfolgskontrolle zu optimieren, erfanden die openQA-Entwickler um Bernhard Wiedemann (SUSE), der openQA im Jahr 2010 initiierte, das Konzept der Needles (Nadeln).

Heuhaufen

Diese Nadeln im Heuhaufen – das folgende Listing zeigt eine Nadel für einen Thunderbird-Test – beschreiben relevante Ausschnitte aus einer Grafik, die identisch sein müssen. Oft ist es ja egal, was sich sonst auf dem Bildschirm tut, Hauptsache dieser Bereich (etwa eine Schaltfläche) wird korrekt dargestellt.

Listing 0: Thunderbird Needle

Diese Nadeln lassen sich auch im Webinterface definieren, per Drag-and-Drop und Mausklick. Alle Ergebnisse und Umgebungsvariablen speichert openQA in Json-Files.

Listing 1: Ergebnisse in results.json:

Listing 2: Variablen in vars.json:

Während die Nadeln den relevanten Ausschnitt eines Fensters angeben, definieren Tests Abläufe, die die virtuelle Maschine durchlaufen soll und die Wunschergebnisse. Das kann ein simples "Bootet das Installationssystem" sein, aber der Komplexität ist keine Grenze gesetzt: openQA testet auch KDE, GNOME und andere grafische Oberflächen. Wie das Listing oben zeigt, lässt sich sogar die initiale Konfiguration von Thunderbird überprüfen. Das openSUSE-Team checkt also auch, ob beim ersten Start von Thunderbird auch wirklich der "New Account"-Wizard startet und ob sich ein Account anlegen lässt.

Die zahllosen Tests sind ohnehin das Kernstück von openQA – und es werden stetig mehr. Richard Brown berichtet stolz: "Wir haben mittlerweile Support für OpenvSwitch und VDE an Bord, wir testen S/390 Mainframe, auch andere Distributionen wie Android und Fedora können wir testen."

Ebenfalls neu ist die "Asset creation": Auf dem letzten als "working" getesteten Tumbleweed-Snapshot lassen die Entwickler weitere Tests ablaufen – das für Tests erstellte Image bleibt also erhalten und dient für Fragen wie "Funktioniert das auch mit der neuesten X11-Variante?", bevor eine neue Tumbleweed-Ausgabe veröffentlicht wird.

Vor allem rund um YaST, SUSEs Setup- und Konfigurationstool tut sich einiges in Sachen Testentwicklung, man entwickelt derzeit viele zusätzliche SLES12-spezifische Tests. Und wer sich hier einbringen will, ist gerne gesehen: Der Anzahl und Komplexität der openQA-Tests ist keine Grenze gesetzt, die Qualität der getesteten Produkte steigt schließlich mit der Anzahl der erfolgreich bestandenen Tests.

Fedora

Dass das auch die Konkurrenz nicht kalt lassen konnte, zeigt die Entwicklung rund um Fedora. Es war ebenfalls Brown, der eine erste Testsuite speziell für Fedora entwickelt hatte. In seinem Vortrag auf der Suse Conference [7] beschreibt er lakonisch, dass die größten Schwierigkeiten dabei gewesen seien, zu verstehen, wie man Fedora überhaupt installiere, weil der Installer Anakonda doch einige andere Herangehensweisen vorweise. Nichtsdestotrotz habe er dann einige Tests entwickelt und so beweisen können, dass openQA selbstverständlich auch andere Linuxe unterstütze. Seine Tests liegen frei zum Download [8].

Auf Red Hats Entwicklerkonferenz DevConf im tschechischen Brno machte dann auch schnell die Runde, dass Red Hat selbst eine openQA-Instanz am Laufen habe, weil man das System als interessant und wertvoll ansehe. Analog zum Open Build Service (auch davon betreibt Red Hat eine eigene Installation) bevorzuge Red Hat wohl eigene Lösungen, anstatt sich ins Community-Angebot einzubringen, heißt es in Nürnberg.

Eigenbau

Dass derlei überhaupt möglich ist, liegt daran, dass SUSE alle Werkzeuge aus seiner Toolchain komplett veröffentlicht hat. Studio, Kiwi, der Build Service und openQA sind Open-Source-Projekte, die sich samt und sonders auch lokal, on Premise installieren lassen. Die meisten der Tools sind webbasiert, im Falle von openQA ist die eigene Installation noch etwas anstrengend, was aber auch daran liegt, dass das Interesse der Anwender eher im Benutzen des Webangebotes liegt, als in der eigenen Installation. Nichtsdestotrotz funktioniert der folgende Weg – die umfassende Dokumentation liegt hier [9]. Wer auf den Quelltext nicht verzichten will, findet das Archiv hier auf Github [10].

Etwas Arbeit

Wer ein wenig Arbeit nicht scheut und den Weg zur eigenen Installation gehen will, der sollte mit openSUSE 13.2 oder Tumbleweed anfangen [11]. Am besten beginnt er mit der Version 13.2 und tauscht gleich mal die Repositories aus. Beispielweise indem er erst das Verzeichnis /etc/zypp/repos.d sichert, und dann die Zypper-Befehle aus dem folgenden Listing aufruft. Zypper ist das komfortable Befehlszeilenfrontend für den Paketmanager der SUSE-Distributionen. Analog zu Yum (Red Hat) und Apt oder Aptitude auf Debian und Ubuntu übernimmt Zypper viele Aufgaben beim Installieren von Paketen, aber auch beim Verwalten von Repositories.

Listing 3:

Ein "zypper dup" upgraded das openSUSE-System zu den aktuellsten Tumbleweed-Paketen, vielleicht ist dann ein Reboot fällig, weil ein neuer Kernel installiert wurde. Danach installiert Zypper openQA auf dem frischgebackenen Tumbleweed-System.

Listing 4:

Let the real work begin...

Und hier beginnt der schwierigere Teil, der auch (noch) nicht optimal dokumentiert ist. Abhängig von Ihren Settings und Vorlieben wird sich das unterschiedlich schwer gestalten. Auf dem SUSE-System bedarf es jetzt eines SSL-enabled Webservers, der auch noch vom Internet aus erreichbar sein muss, weil die Anmeldung bei openQA über OpenID läuft [12]. Das mag in diversen Firewall-Szenarios Schwierigkeiten bereiten.

Hat das geklappt, lassen sich mit einfachen Befehlen (die Dokumentation ist hier wiederum sehr hilfreich) die ersten openQA-Worker installieren (zypper in openQA-worker), die Needles für die Standardtests mit dem Skript Fetchneedles herunterladen (/usr/share/openqa/script/fetchneedles) und schon kann es losgehen. Dumm nur, wenn – wie beim Erstellen dieses Artikels geschehen – das Importieren eines ISO-Images nicht funktionierte. Laut Aussage der Entwickler ist das aber "in der Git-Version von openQA schon behoben" Normalerweise lässt sich jedes lokale Iso in /var/lib/openqa/factory/iso mit dem Skript "/usr/share/openqa/script/client isos post" gefolgt von den für die jeweilige Distribution spezifischen Variablen und Parametern laden. Nach erfolgreichem Import sollte das Image im Webinterface von openQA auftauchen – und fortan läuft alles so wie auf der Webseite des Projektes, nur halt mit vermutlich deutlich weniger Ressourcen. Jetzt lassen sich die ersten Worker starten (Webinterface oder Kommandozeile), Tests definieren oder bestehende Tests ausprobieren – dem Spieltrieb sind keine Grenzen gesetzt.

Tests erwünscht

Das openQA-Team freut sich übrigens über alle Beiträge, nicht nur Sourcecode und Dokumentation. Gerade die Vielzahl unterschiedlicher Tests machen den Erfolg von openQA aus. Und das ist etwas, wo gerade die Community deutlich effizienter ist als ein Entwicklerteam oder eine Firma. Es existiert eine Dokumentation zum Schreiben von Tests für openQA [13] – Grenzen sind wirklich keine gesetzt, sogar Android lässt sich mit openQA testen [14].

Autor

Markus Feilner

Markus Feilner ist ein Linux-Spezialist aus Regensburg, der seit 1994 mit dem freien Betriebssystem als Autor, Trainer, Consultant und Journalist arbeitet. Der Conch-Diplomat, Minister der Universal Life Church und Jedi-Ritter...
>> Weiterlesen
botMessage_toctoc_comments_9210