GKernelCI V2

[aliceinwire]

diagram:

• Divide GBuildbot
• Make Gdocker start by docker-compose up -d
• Gdocker have tyrian-theme
• Move all the scripts parts to Ghelper
• Clean old builder configuration
• Create building factory
• Make lava testing script from Gbuildbot
• lava can boot a gentoo testing artifact
• Creating Gentoo rootfs weekly from buildbot worker
• lava can boot the created rootfs
• send KCIDB notifications
• Add lava test other than boot
• Encrypt secrets with blackbox

[aliceinwire]

• we still need a working lava configuration branch on https://github.com/GKernelCI/Glava

[montjoie]

Topic: LAVA instance
The LAVA instance should be persistent.
It could be a poped one by buildbot, but this will:

• increase a lot time needed due to setup time
• will made things harder to debug and/or use real boards

Furthermore, having persistent LAVA instance permit developper to use them out-of-buildbot. (for hacking sessions for example)

EXTRA-bonus: Having persistent LAVA instance permit to share them to other CI project. ( kernelci ;) )

[montjoie]

Topic: rootfs type choice
Before doing LAVA job definition, you need to choose how the DUT(Device under test) will mount rootfs.
LAVA support lot of way like ramdisk, NFS, NBD.
The choice change which rootfs format must be provided (ramdisk need cpio.gz, NFS need tar.XX, NBD need ext2 image)

Very probably ramdisk should be avoided, a gentoo rootfs is too big, while on qemu-with-lot-of-ram it could work (but I fail on it), on real physical board it will be impossible.

On qemu you could use rootfs as hard disk image but this method is not available on real boards.
A common (to qemu and physical boards) way is root-on-NFS.
NBD is an option but LAVA does not support it on qemu.

Note: unrelated to rootfs type LAVA will download it anyway, so your fileserver must be an HTTP server.

[aliceinwire]

Topic: LAVA instance
The LAVA instance should be persistent.

yes, the LAVA instance will be persistent.

[aliceinwire]

Topic: rootfs type choice
Before doing LAVA job definition, you need to choose how the DUT(Device under test) will mount rootfs.
LAVA support lot of way like ramdisk, NFS, NBD.
The choice change which rootfs format must be provided (ramdisk need cpio.gz, NFS need tar.XX, NBD need ext2 image)

Very probably ramdisk should be avoided, a gentoo rootfs is too big, while on qemu-with-lot-of-ram it could work (but I fail on it), on real physical board it will be impossible.

On qemu you could use rootfs as hard disk image but this method is not available on real boards.
A common (to qemu and physical boards) way is root-on-NFS.
NBD is an option but LAVA does not support it on qemu.

Thanks I will take this in considerations.

Note: unrelated to rootfs type LAVA will download it anyway, so your fileserver must be an HTTP server.

yes the fileserver is http.
https://github.com/GKernelCI/Gfileserver

[aliceinwire]

• Add hard disk space to the current servers

[aliceinwire]

hard disk space as been added to both machine (thanks gentoo-infra)

[aliceinwire]

GKernelCI is currently sending reports to KCIDB
http://140.211.166.171:8010/#/builders/7/builds/12/steps/11/logs/stdio

[aliceinwire]

Currently we are not making our own rootfs but we are using stage3 instead.
As now is enough good for closing the rootfs tasks.

[aliceinwire]

• Restart lava server for upgrading the machine

[aliceinwire]

As currently GKernelCI v2 surpassed the features of GKernelCI v1 we can close this issue