1
00:00:03,767 --> 00:00:05,718
Das ist testbed-qemu.

2
00:00:05,718 --> 00:00:09,619
Es bootet einen echten
prplOS-Router in QEMU.

3
00:00:10,120 --> 00:00:14,300
Diesen Router nennen wir
Device under Test, kurz DUT.

4
00:00:14,800 --> 00:00:19,373
Es führt die cram-Tests von
prplOS aus, dieselben wie die CI.

5
00:00:19,873 --> 00:00:24,837
Es bootet das DUT auf Ihrem Rechner,
aus einem prplOS-Image Ihrer Wahl.

6
00:00:29,197 --> 00:00:33,692
Docker Compose oder Podman ohne Root
startet den Container testbed-qemu.

7
00:00:33,692 --> 00:00:38,740
Im Container führt der Testhost cram,
SSH und die serielle Konsole aus.

8
00:00:38,740 --> 00:00:43,235
Daneben bootet QEMU das DUT und
nutzt KVM, wenn der Host es bietet.

9
00:00:43,235 --> 00:00:45,586
Drei Leitungen verbinden beide Seiten.

10
00:00:45,586 --> 00:00:47,937
Das LAN trägt Ihren Testverkehr.

11
00:00:47,937 --> 00:00:52,086
Das WAN bezieht seine Adresse
per DHCP von einem Server im Container

12
00:00:52,086 --> 00:00:54,922
und erreicht darüber die Außenwelt.

13
00:00:54,922 --> 00:00:57,480
Die dritte ist die serielle Konsole.

14
00:00:57,480 --> 00:01:02,805
Der Host gibt dem Container den
prplOS-Baum und das Image, nur lesbar.

15
00:01:02,805 --> 00:01:07,092
Außerdem einen Ordner für Logs
und Ergebnisse und, für die Shell,

16
00:01:07,092 --> 00:01:09,374
einen Ordner für ihre dauerhafte Disk.

17
00:01:13,734 --> 00:01:19,603
Sie brauchen Linux mit Docker Compose
oder Podman ohne Root, dazu git und make.

18
00:01:19,603 --> 00:01:23,020
Mit KVM bootet das DUT
in etwa einer halben Minute.

19
00:01:23,020 --> 00:01:26,065
Ohne KVM läuft QEMU trotzdem, nur langsam.

20
00:01:26,565 --> 00:01:29,388
Klonen Sie das Repository testbed-qemu.

21
00:01:32,900 --> 00:01:34,361
Dann folgt make fetch.

22
00:01:34,361 --> 00:01:38,892
Es lädt das festgelegte prplOS-Image
herunter und prüft seine Prüfsumme.

23
00:01:38,892 --> 00:01:43,716
Es schreibt auch einen gekürzten
prplOS-Testbaum in den Ordner qa-cache.

24
00:01:44,216 --> 00:01:46,580
Dann folgt make test-qemu-shell.

25
00:01:46,580 --> 00:01:49,575
Beim ersten Mal baut es den Container.

26
00:01:49,575 --> 00:01:53,595
Es bootet das DUT und öffnet
eine Shell im Container.

27
00:01:57,955 --> 00:02:01,838
Test-Buckets wie smoke brauchen
einen echten prplOS-Klon,

28
00:02:01,838 --> 00:02:04,655
nicht den gekürzten Baum aus make fetch.

29
00:02:04,655 --> 00:02:08,614
Klonen Sie also prplOS
auf dem Commit, den testbed-qemu festlegt.

30
00:02:09,114 --> 00:02:10,802
Dann folgt make test-qemu.

31
00:02:10,802 --> 00:02:14,318
Geben Sie den Klon an und
wählen Sie den Bucket smoke.

32
00:02:14,318 --> 00:02:18,256
Es bootet ein neues DUT und
wartet auf SSH und das Datenmodell.

33
00:02:18,256 --> 00:02:23,038
Dann laufen die sechs Tests von smoke,
die der Klon für dieses Board listet.

34
00:02:25,502 --> 00:02:30,410
In der prplOS-CI kann ein Merge Request
denselben Bucket smoke von Hand starten,

35
00:02:30,410 --> 00:02:33,967
als QEMU-Job im selben
Container testbed-qemu.

36
00:02:33,967 --> 00:02:37,453
Die sechs Tests von smoke laufen,
einer wird übersprungen.

37
00:02:37,453 --> 00:02:39,444
Dann laufen zwei Post-Tests.

38
00:02:39,444 --> 00:02:44,708
Der Lauf bestand, und der Job sammelte
trotzdem Debug-Informationen vom DUT.

39
00:02:44,708 --> 00:02:47,838
Der Job läuft auf einem
GitLab-Runner mit KVM.

40
00:02:52,198 --> 00:02:55,002
Der Shell-Modus ist make test-qemu-shell.

41
00:02:55,002 --> 00:02:59,409
Sie bekommen sofort eine Shell,
während das DUT noch bootet.

42
00:02:59,967 --> 00:03:01,655
Drücken Sie Pfeil nach oben.

43
00:03:01,655 --> 00:03:07,875
Die Shell-Historie enthält bereits
testbed-qemu wait und testbed-qemu ssh.

44
00:03:07,875 --> 00:03:12,673
Der Befehl wait blockiert,
bis das DUT über SSH antwortet.

45
00:03:12,673 --> 00:03:16,138
Dann öffnet ssh eine
Root-Shell auf dem DUT.

46
00:03:16,638 --> 00:03:21,446
Jetzt arbeiten Sie als root auf dem DUT,
etwa um seine Routen aufzulisten.

47
00:03:25,638 --> 00:03:31,755
Für die serielle Konsole statt SSH
starten Sie testbed-qemu console.

48
00:03:31,755 --> 00:03:33,909
Drücken Sie Enter für einen Prompt.

49
00:03:33,909 --> 00:03:36,924
Strg-] bringt Sie zurück in die Shell.

50
00:03:41,284 --> 00:03:42,410
Nun ein neuer Test.

51
00:03:42,410 --> 00:03:47,967
Legen Sie ihn im lokalen prplOS-Baum
ab: Die Shell sieht dieselben Dateien.

52
00:03:47,967 --> 00:03:52,848
Ein cram-Test ist eine Textdatei: ein
Befehl, dann die erwartete Ausgabe.

53
00:03:52,848 --> 00:03:56,828
Dieser prüft, dass SSH
das DUT über das LAN erreicht.

54
00:03:57,328 --> 00:03:59,474
Ausführen mit testbed-qemu cram.

55
00:03:59,474 --> 00:04:02,480
Er läuft gegen das bereits gestartete DUT,

56
00:04:02,480 --> 00:04:05,270
so können Sie ihn ohne
neuen Boot wiederholen.

57
00:04:05,770 --> 00:04:09,455
Nun machen Sie ihn kaputt:
Ändern Sie die erwartete Ausgabe.

58
00:04:12,270 --> 00:04:13,194
Erneut starten.

59
00:04:13,194 --> 00:04:18,593
Cram gibt einen Diff aus: die Zeile, die
der Test erwartet, und die, die er bekam.

60
00:04:20,770 --> 00:04:26,064
Stimmt die Ausgabe, übernehmen Sie sie
mit dem cp-Befehl, den der Runner ausgibt,

61
00:04:26,064 --> 00:04:26,858
auf dem Host.

62
00:04:32,630 --> 00:04:34,940
Scheitert ein QEMU-Job in der CI,

63
00:04:34,940 --> 00:04:41,043
reproduzieren Sie ihn zuerst lokal,
mit demselben Test über make test-qemu.

64
00:04:41,543 --> 00:04:45,620
Hier läuft der Reboot-Test aus den
eigenen Tests von testbed-qemu.

65
00:04:45,620 --> 00:04:50,770
Er schreibt eine Markerdatei, startet das
DUT neu und wartet, bis SSH zurück ist.

66
00:04:50,770 --> 00:04:55,706
Dann prüft er, dass der Marker überlebt
hat und die Uptime zurückgesetzt ist.

67
00:04:55,706 --> 00:04:59,568
Die CI von testbed-qemu selbst
startet ihn in jeder Pipeline.

68
00:05:00,068 --> 00:05:03,827
Ein Batch-Lauf mit make test-qemu
bootet immer eine eigene

69
00:05:03,827 --> 00:05:06,054
Kopie des Images im Werkszustand.

70
00:05:06,054 --> 00:05:10,092
Beim ersten Mal flasht die Shell
ihre eigene Disk aus dem Image

71
00:05:10,092 --> 00:05:14,755
und behält diese Disk zwischen Sitzungen,
im Ordner qemu-disk-state.

72
00:05:14,755 --> 00:05:17,748
Für einen sauberen Start:
testbed-qemu disk reset.

73
00:05:17,748 --> 00:05:21,438
Danach ist der nächste
kontrollierte Boot im Werkszustand.

74
00:05:21,938 --> 00:05:23,150
Scheitert ein Lauf,

75
00:05:23,150 --> 00:05:26,786
sammelt testbed-qemu
Debug-Informationen vom DUT,

76
00:05:26,786 --> 00:05:28,925
bevor es das DUT abschaltet.

77
00:05:28,925 --> 00:05:34,914
Der prplOS-CI-Job von vorhin sammelt
sie bei jedem Lauf, auch bei Erfolg.

78
00:05:34,914 --> 00:05:38,265
In einer Live-Shell fordern
Sie sie jederzeit an.

79
00:05:42,625 --> 00:05:45,473
testbed-qemu hat auch
einen Skill für Agenten.

80
00:05:45,473 --> 00:05:49,880
Die Skill-Datei listet die genauen
Befehle, Exit-Codes und ein Runbook.

81
00:05:49,880 --> 00:05:53,067
Hier arbeitet Claude Code
mit Sonnet im Auto-Modus.

82
00:05:53,067 --> 00:05:56,729
Es lädt den Skill und prüft
den Host mit dem Doctor,

83
00:05:56,729 --> 00:05:59,373
der zuerst das Container-Image baut.

84
00:05:59,373 --> 00:06:03,984
Dann bootet der Test das DUT in QEMU,
wartet auf SSH und das Datenmodell

85
00:06:03,984 --> 00:06:06,086
und startet den Konnektivitätstest.

86
00:06:06,086 --> 00:06:09,679
Es meldet den bestandenen Test,
mit den Post-Checks,

87
00:06:09,679 --> 00:06:11,917
den Bootzeiten und den Artefakten.

88
00:06:11,917 --> 00:06:16,324
Die Statuszeile zeigt, was der Lauf
an Tokens, Zeit und Geld gekostet hat.

89
00:06:18,985 --> 00:06:24,049
testbed-qemu bootet das prplOS-Image,
das Sie holen, mit vollem Userspace.

90
00:06:24,049 --> 00:06:27,739
Es gibt dem DUT ein echtes
LAN, WAN und eine serielle Konsole.

91
00:06:27,739 --> 00:06:30,198
Echte Hardware ersetzt es nicht,

92
00:06:30,198 --> 00:06:34,033
und es bildet weder einen Switch
noch ein Mobilfunk-Gateway nach.