Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GKernelCI V2 #6

Closed
13 tasks done
aliceinwire opened this issue Aug 21, 2020 · 11 comments
Closed
13 tasks done

GKernelCI V2 #6

aliceinwire opened this issue Aug 21, 2020 · 11 comments
Assignees
Milestone

Comments

@aliceinwire
Copy link
Member

aliceinwire commented Aug 21, 2020

diagram:
GKernelCI_V2

  • 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 aliceinwire self-assigned this Aug 21, 2020
@aliceinwire aliceinwire added this to the GKernelCI V2 milestone Aug 21, 2020
@aliceinwire
Copy link
Member Author

aliceinwire commented Nov 5, 2020

@montjoie
Copy link
Contributor

montjoie commented Nov 9, 2020

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
Copy link
Contributor

montjoie commented Nov 9, 2020

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
Copy link
Member Author

Topic: LAVA instance
The LAVA instance should be persistent.

yes, the LAVA instance will be persistent.

@aliceinwire
Copy link
Member Author

aliceinwire commented Dec 3, 2020

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
Copy link
Member Author

aliceinwire commented Dec 4, 2020

  • Add hard disk space to the current servers

@aliceinwire
Copy link
Member Author

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

@aliceinwire
Copy link
Member Author

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

@aliceinwire
Copy link
Member Author

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
Copy link
Member Author

aliceinwire commented Feb 1, 2021

  • Restart lava server for upgrading the machine

@aliceinwire
Copy link
Member Author

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

@aliceinwire aliceinwire unpinned this issue Feb 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants