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

2
00:00:05,718 --> 00:00:09,619
Il démarre un vrai
routeur prplOS dans QEMU.

3
00:00:10,120 --> 00:00:14,300
Nous appelons ce routeur
l'équipement sous test, ou DUT.

4
00:00:14,800 --> 00:00:19,373
Il exécute les tests cram de prplOS,
les mêmes que ceux de la CI.

5
00:00:19,873 --> 00:00:24,837
Il démarre le DUT sur votre ordinateur,
depuis l'image prplOS choisie.

6
00:00:29,197 --> 00:00:33,692
Docker Compose ou Podman rootless
exécute le conteneur testbed-qemu.

7
00:00:33,692 --> 00:00:38,740
Dans le conteneur, l'hôte de test
exécute cram, SSH et la console série.

8
00:00:38,740 --> 00:00:43,235
À côté, QEMU démarre le DUT et
utilise KVM si l'hôte en dispose.

9
00:00:43,235 --> 00:00:45,586
Trois câbles relient les deux côtés.

10
00:00:45,586 --> 00:00:47,937
Le LAN transporte votre trafic de test.

11
00:00:47,937 --> 00:00:52,086
Le WAN reçoit son adresse
d'un serveur DHCP du conteneur,

12
00:00:52,086 --> 00:00:54,922
et passe par lui pour joindre l'extérieur.

13
00:00:54,922 --> 00:00:57,480
Le troisième câble est la console série.

14
00:00:57,480 --> 00:01:02,805
L'hôte fournit au conteneur l'arbre prplOS
et, en lecture seule, l'image prplOS.

15
00:01:02,805 --> 00:01:07,092
Il fournit aussi un dossier de logs
et de résultats et, pour le shell,

16
00:01:07,092 --> 00:01:09,374
un dossier pour son disque persistant.

17
00:01:13,734 --> 00:01:19,603
Il faut un hôte Linux avec Docker Compose
ou Podman rootless, plus git et make.

18
00:01:19,603 --> 00:01:23,020
Avec KVM, le DUT démarre en
une trentaine de secondes.

19
00:01:23,020 --> 00:01:26,065
Sans KVM, QEMU marche encore,
mais lentement.

20
00:01:26,565 --> 00:01:29,388
Clonez le dépôt testbed-qemu.

21
00:01:32,900 --> 00:01:34,361
Puis lancez make fetch.

22
00:01:34,361 --> 00:01:38,892
Il télécharge l'image prplOS épinglée
et vérifie sa somme de contrôle.

23
00:01:38,892 --> 00:01:43,716
Il écrit aussi un arbre de test prplOS
allégé dans le dossier qa-cache.

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

25
00:01:46,580 --> 00:01:49,575
Au premier usage, il
construit le conteneur.

26
00:01:49,575 --> 00:01:53,595
Il démarre le DUT et ouvre
un shell dans le conteneur.

27
00:01:57,955 --> 00:02:01,838
Les buckets de test comme smoke
nécessitent un vrai clone prplOS,

28
00:02:01,838 --> 00:02:04,655
pas l'arbre allégé de make fetch.

29
00:02:04,655 --> 00:02:08,614
Clonez donc prplOS au commit
épinglé par testbed-qemu.

30
00:02:09,114 --> 00:02:10,802
Puis lancez make test-qemu.

31
00:02:10,802 --> 00:02:14,318
Pointez-le vers le clone et
choisissez le bucket smoke.

32
00:02:14,318 --> 00:02:18,256
Il démarre un DUT neuf et attend
SSH et le modèle de données.

33
00:02:18,256 --> 00:02:23,038
Puis il exécute les six tests smoke
que le clone liste pour cette carte.

34
00:02:25,502 --> 00:02:30,410
Dans la CI prplOS, une merge request peut
lancer à la main le même bucket smoke,

35
00:02:30,410 --> 00:02:33,967
comme job QEMU, dans ce même
conteneur testbed-qemu.

36
00:02:33,967 --> 00:02:37,453
Il exécute les six tests smoke
et en ignore un.

37
00:02:37,453 --> 00:02:39,444
Puis il lance deux post-tests.

38
00:02:39,444 --> 00:02:44,708
L'exécution a réussi, le job a quand même
collecté des infos de débogage du DUT.

39
00:02:44,708 --> 00:02:47,838
Le job tourne sur un runner GitLab
doté de KVM.

40
00:02:52,198 --> 00:02:55,002
Le mode shell, c'est make test-qemu-shell.

41
00:02:55,002 --> 00:02:59,409
Vous obtenez un shell aussitôt,
alors que le DUT démarre encore.

42
00:02:59,967 --> 00:03:01,655
Appuyez sur la flèche haut.

43
00:03:01,655 --> 00:03:07,875
L'historique du shell contient déjà
testbed-qemu wait et testbed-qemu ssh.

44
00:03:07,875 --> 00:03:12,673
La commande wait bloque jusqu'à
ce que le DUT réponde en SSH.

45
00:03:12,673 --> 00:03:16,138
Puis ssh ouvre un shell root sur le DUT.

46
00:03:16,638 --> 00:03:21,446
Vous voilà en root sur le DUT,
par exemple pour lister ses routes.

47
00:03:25,638 --> 00:03:31,755
S'il vous faut la console série, pas SSH,
lancez testbed-qemu console.

48
00:03:31,755 --> 00:03:33,909
Appuyez sur Entrée pour une invite.

49
00:03:33,909 --> 00:03:36,924
Ctrl-] vous ramène au shell.

50
00:03:41,284 --> 00:03:42,410
Ajoutez un test.

51
00:03:42,410 --> 00:03:47,967
Enregistrez-le dans l'arbre prplOS local,
car le shell voit les mêmes fichiers.

52
00:03:47,967 --> 00:03:52,848
Un test cram est un fichier texte, avec
une commande puis la sortie attendue.

53
00:03:52,848 --> 00:03:56,828
Celui-ci vérifie que SSH
atteint le DUT via le LAN.

54
00:03:57,328 --> 00:03:59,474
Lancez-le avec testbed-qemu cram.

55
00:03:59,474 --> 00:04:02,480
Il s'exécute sur le DUT déjà démarré,

56
00:04:02,480 --> 00:04:05,270
vous pouvez donc le relancer
sans redémarrer.

57
00:04:05,770 --> 00:04:09,455
Puis cassez-le, changez
la sortie attendue dans le fichier.

58
00:04:12,270 --> 00:04:13,194
Relancez-le.

59
00:04:13,194 --> 00:04:18,593
Cram affiche un diff avec la ligne que
le test attend et celle qu'il a reçue.

60
00:04:20,770 --> 00:04:26,064
Si la nouvelle sortie est bonne,
acceptez-la avec la commande cp du runner,

61
00:04:26,064 --> 00:04:26,858
sur l'hôte.

62
00:04:32,630 --> 00:04:34,940
Quand un job QEMU échoue en CI,

63
00:04:34,940 --> 00:04:41,043
reproduisez-le d'abord en local,
avec le même test et make test-qemu.

64
00:04:41,543 --> 00:04:45,620
Ici, nous lançons le test
de redémarrage de testbed-qemu lui-même.

65
00:04:45,620 --> 00:04:50,770
Il écrit un fichier marqueur, redémarre
le DUT et attend le retour de SSH.

66
00:04:50,770 --> 00:04:55,706
Puis il vérifie que le marqueur a survécu
et que l'uptime a été remis à zéro.

67
00:04:55,706 --> 00:04:59,568
La CI de testbed-qemu lance
ce test dans chaque pipeline.

68
00:05:00,068 --> 00:05:03,827
En batch, make test-qemu démarre
toujours une copie privée

69
00:05:03,827 --> 00:05:06,054
de l'image, à l'état d'usine.

70
00:05:06,054 --> 00:05:10,092
Le shell flashe son propre disque
depuis l'image au premier usage,

71
00:05:10,092 --> 00:05:14,755
et garde ce disque entre les sessions,
dans le dossier qemu-disk-state.

72
00:05:14,755 --> 00:05:17,748
Pour recommencer, lancez
testbed-qemu disk reset.

73
00:05:17,748 --> 00:05:21,438
Le démarrage contrôlé suivant
repart alors de l'état d'usine.

74
00:05:21,938 --> 00:05:23,150
En cas d'échec,

75
00:05:23,150 --> 00:05:26,786
testbed-qemu collecte
des infos de débogage sur le DUT

76
00:05:26,786 --> 00:05:28,925
avant d'éteindre le DUT.

77
00:05:28,925 --> 00:05:34,914
Le job CI prplOS vu plus tôt les collecte
à chaque exécution, même réussie.

78
00:05:34,914 --> 00:05:38,265
Dans un shell ouvert,
demandez-les à tout moment.

79
00:05:42,625 --> 00:05:45,473
testbed-qemu inclut aussi
une skill pour agents.

80
00:05:45,473 --> 00:05:49,880
Son fichier liste les commandes exactes,
codes de sortie et un runbook.

81
00:05:49,880 --> 00:05:53,067
Ici, Claude Code, sur Sonnet,
travaille en mode auto.

82
00:05:53,067 --> 00:05:56,729
Il charge la skill et vérifie
l'hôte avec la commande doctor,

83
00:05:56,729 --> 00:05:59,373
qui construit d'abord
l'image du conteneur.

84
00:05:59,373 --> 00:06:03,984
Puis le test démarre le DUT dans QEMU,
attend SSH et le modèle de données,

85
00:06:03,984 --> 00:06:06,086
et lance le test de connectivité.

86
00:06:06,086 --> 00:06:09,679
Il signale la réussite du test,
avec les post-tests,

87
00:06:09,679 --> 00:06:11,917
les temps de boot et les artefacts.

88
00:06:11,917 --> 00:06:16,324
La ligne d'état affiche le coût
de l'exécution en tokens, temps et argent.

89
00:06:18,985 --> 00:06:24,049
testbed-qemu démarre l'image prplOS que
vous récupérez, avec tout son userspace.

90
00:06:24,049 --> 00:06:27,739
Il donne au DUT de vrais LAN,
WAN et console série.

91
00:06:27,739 --> 00:06:30,198
Il ne remplace pas du vrai matériel,

92
00:06:30,198 --> 00:06:34,033
et ne simule ni un switch
ni une passerelle cellulaire.