1
00:00:03,767 --> 00:00:05,718
Este é o testbed-qemu.

2
00:00:05,718 --> 00:00:09,619
Ele inicializa um roteador
prplOS real dentro do QEMU.

3
00:00:10,120 --> 00:00:14,300
Chamamos esse roteador de
dispositivo sob teste, ou DUT.

4
00:00:14,800 --> 00:00:19,373
Ele executa os testes cram do
prplOS, os mesmos que a CI executa.

5
00:00:19,873 --> 00:00:24,837
Ele inicializa o DUT no seu computador,
com a imagem prplOS que você escolher.

6
00:00:29,197 --> 00:00:33,692
Docker Compose ou Podman rootless
roda o contêiner testbed-qemu.

7
00:00:33,692 --> 00:00:38,740
Dentro do contêiner, o host de teste
roda cram, SSH e o console serial.

8
00:00:38,740 --> 00:00:43,235
Ao lado, o QEMU inicializa o
DUT e usa KVM se o host tiver.

9
00:00:43,235 --> 00:00:45,586
Três cabos conectam os dois lados.

10
00:00:45,586 --> 00:00:47,937
A LAN leva o seu tráfego de teste.

11
00:00:47,937 --> 00:00:52,086
A WAN recebe seu endereço de
um servidor DHCP no contêiner,

12
00:00:52,086 --> 00:00:54,922
e chega ao mundo externo através dele.

13
00:00:54,922 --> 00:00:57,480
O terceiro cabo é o console serial.

14
00:00:57,480 --> 00:01:02,805
O host dá ao contêiner a árvore prplOS
e, somente leitura, a imagem prplOS.

15
00:01:02,805 --> 00:01:07,092
Também passa uma pasta para logs
e resultados e, para o shell,

16
00:01:07,092 --> 00:01:09,374
uma pasta para seu disco persistente.

17
00:01:13,734 --> 00:01:19,603
É preciso um host Linux com Docker Compose
ou Podman rootless, mais git e make.

18
00:01:19,603 --> 00:01:23,020
Com KVM, o DUT inicializa
em cerca de meio minuto.

19
00:01:23,020 --> 00:01:26,065
Sem ele, o QEMU ainda
funciona, mas devagar.

20
00:01:26,565 --> 00:01:29,388
Clone o repositório testbed-qemu.

21
00:01:32,900 --> 00:01:34,361
Depois, rode make fetch.

22
00:01:34,361 --> 00:01:38,892
Ele baixa a imagem prplOS fixada
e verifica o checksum dela.

23
00:01:38,892 --> 00:01:43,716
Também grava uma árvore de testes
prplOS reduzida na pasta qa-cache.

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

25
00:01:46,580 --> 00:01:49,575
No primeiro uso, ele constrói o contêiner.

26
00:01:49,575 --> 00:01:53,595
Ele inicializa o DUT e
abre um shell no contêiner.

27
00:01:57,955 --> 00:02:01,838
Buckets de teste como smoke
exigem um clone real do prplOS,

28
00:02:01,838 --> 00:02:04,655
não a árvore reduzida do make fetch.

29
00:02:04,655 --> 00:02:08,614
Por isso, clone o prplOS no
commit que o testbed-qemu fixa.

30
00:02:09,114 --> 00:02:10,802
Então rode make test-qemu.

31
00:02:10,802 --> 00:02:14,318
Indique o clone e
selecione o smoke bucket.

32
00:02:14,318 --> 00:02:18,256
Ele inicializa um DUT novo e
espera o SSH e o modelo de dados.

33
00:02:18,256 --> 00:02:23,038
Depois, executa os seis testes smoke
que o clone lista para esta placa.

34
00:02:25,502 --> 00:02:30,410
Na CI do prplOS, um merge request pode
iniciar o mesmo smoke bucket manualmente,

35
00:02:30,410 --> 00:02:33,967
como um job QEMU, neste
mesmo contêiner testbed-qemu.

36
00:02:33,967 --> 00:02:37,453
Ele executa os seis testes
smoke e pula um deles.

37
00:02:37,453 --> 00:02:39,444
Depois, roda dois testes post.

38
00:02:39,444 --> 00:02:44,708
A execução passou, e mesmo assim o job
coletou informações de debug do DUT.

39
00:02:44,708 --> 00:02:47,838
O job roda em um runner
do GitLab que tem KVM.

40
00:02:52,198 --> 00:02:55,002
O modo shell é o make test-qemu-shell.

41
00:02:55,002 --> 00:02:59,409
Você tem um shell na hora,
com o DUT ainda inicializando.

42
00:02:59,967 --> 00:03:01,655
Pressione a seta para cima.

43
00:03:01,655 --> 00:03:07,875
O histórico do shell já contém
testbed-qemu wait e testbed-qemu ssh.

44
00:03:07,875 --> 00:03:12,673
O comando wait bloqueia até
o DUT responder por SSH.

45
00:03:12,673 --> 00:03:16,138
Então o ssh abre um shell de root no DUT.

46
00:03:16,638 --> 00:03:21,446
Agora você trabalha no DUT como root,
por exemplo para listar as rotas.

47
00:03:25,638 --> 00:03:31,755
Se você precisar do console serial em
vez do SSH, rode testbed-qemu console.

48
00:03:31,755 --> 00:03:33,909
Pressione Enter para ver o prompt.

49
00:03:33,909 --> 00:03:36,924
Ctrl + fecha colchete
(Ctrl-]) volta ao shell.

50
00:03:41,284 --> 00:03:42,410
Adicione um teste.

51
00:03:42,410 --> 00:03:47,967
Salve na árvore prplOS do seu computador:
o shell vê os mesmos arquivos.

52
00:03:47,967 --> 00:03:52,848
Um teste cram é um arquivo de texto:
um comando e depois a saída esperada.

53
00:03:52,848 --> 00:03:56,828
Este verifica se o SSH
chega ao DUT pela LAN.

54
00:03:57,328 --> 00:03:59,474
Rode com testbed-qemu cram.

55
00:03:59,474 --> 00:04:02,480
Ele roda no DUT que já está ligado,

56
00:04:02,480 --> 00:04:05,270
então dá para rodar de novo sem novo boot.

57
00:04:05,770 --> 00:04:09,455
Agora quebre: mude a
saída esperada no arquivo.

58
00:04:12,270 --> 00:04:13,194
Rode de novo.

59
00:04:13,194 --> 00:04:18,593
O cram mostra um diff: a linha que o
teste espera e a linha que ele obteve.

60
00:04:20,770 --> 00:04:26,064
Se a nova saída estiver certa, aceite:
rode o comando cp que o runner mostra,

61
00:04:26,064 --> 00:04:26,858
no host.

62
00:04:32,630 --> 00:04:34,940
Quando um job QEMU falha na CI,

63
00:04:34,940 --> 00:04:41,043
reproduza primeiro no seu computador:
rode o mesmo teste com make test-qemu.

64
00:04:41,543 --> 00:04:45,620
Aqui rodamos o teste de reboot dos
testes do próprio testbed-qemu.

65
00:04:45,620 --> 00:04:50,770
Ele grava um arquivo marcador,
reinicia o DUT e espera o SSH voltar.

66
00:04:50,770 --> 00:04:55,706
Depois verifica se o marcador
sobreviveu e se o uptime foi zerado.

67
00:04:55,706 --> 00:04:59,568
A própria CI do testbed-qemu
roda este teste em cada pipeline.

68
00:05:00,068 --> 00:05:03,827
Em lote, make test-qemu sempre
inicializa uma cópia privada

69
00:05:03,827 --> 00:05:06,054
da imagem, recém-saída de fábrica.

70
00:05:06,054 --> 00:05:10,092
O shell grava seu próprio disco
com a imagem no primeiro uso,

71
00:05:10,092 --> 00:05:14,755
e mantém esse disco entre sessões,
na pasta qemu-disk-state.

72
00:05:14,755 --> 00:05:17,748
Para zerar, rode testbed-qemu disk reset.

73
00:05:17,748 --> 00:05:21,438
Depois, o próximo boot controlado
volta ao estado de fábrica.

74
00:05:21,938 --> 00:05:23,150
Se a execução falha,

75
00:05:23,150 --> 00:05:26,786
o testbed-qemu coleta
informações de debug do DUT

76
00:05:26,786 --> 00:05:28,925
antes de desligar o DUT.

77
00:05:28,925 --> 00:05:34,914
O job de CI do prplOS que você viu antes
coleta isso sempre, mesmo quando passa.

78
00:05:34,914 --> 00:05:38,265
Em um shell ativo, você pode
pedir isso quando quiser.

79
00:05:42,625 --> 00:05:45,473
testbed-qemu também traz
uma skill para agentes.

80
00:05:45,473 --> 00:05:49,880
O arquivo da skill lista os comandos
exatos, códigos de saída e um runbook.

81
00:05:49,880 --> 00:05:53,067
Aqui o Claude Code, com
Sonnet, roda em modo auto.

82
00:05:53,067 --> 00:05:56,729
Ele carrega a skill e
verifica o host com o doctor,

83
00:05:56,729 --> 00:05:59,373
que primeiro constrói
a imagem do contêiner.

84
00:05:59,373 --> 00:06:03,984
Depois o teste inicializa o DUT no
QEMU, espera o SSH e o modelo de dados,

85
00:06:03,984 --> 00:06:06,086
e roda o teste de conectividade.

86
00:06:06,086 --> 00:06:09,679
Ele informa que o teste passou,
com as verificações post,

87
00:06:09,679 --> 00:06:11,917
os tempos de boot e os artefatos.

88
00:06:11,917 --> 00:06:16,324
A linha de status mostra o custo da
execução em tokens, tempo e dinheiro.

89
00:06:18,985 --> 00:06:24,049
O testbed-qemu inicializa a imagem prplOS
que você baixa, com todo o userspace.

90
00:06:24,049 --> 00:06:27,739
Ele dá ao DUT uma LAN, uma
WAN e um console serial reais.

91
00:06:27,739 --> 00:06:30,198
Ele não substitui hardware real,

92
00:06:30,198 --> 00:06:34,033
e não modela nem um switch
nem um gateway celular.