Hi folks,

We held our regular weekly design meeting today via Hangout. Summary of brief discussion:

1. [Dan/Anibal] fastboot NFS/ramdisk support 1. LAVA can almost do it today 2. https://git.lavasoftware.org/lava/lava/issues/271 1. See also this discussion https://lists.lavasoftware.org/ pipermail/lava-devel/2019-May/000047.html 3. How best to describe things in a job? 1. new deploy method? 2. name? fastboot-nfs? fastboot-noflash? bob? 4. How does this interact with the generation of the image? 1. if the user makes/tweaks the image inside an lxc, how do we pass details in/out? 2. For creating boot images or binaries, the idea is to implement a deploy method that can either run commands directly on the dispatcher (which may happen to be inside a container) or inside a container controlled by LAVA. This will replace the current LXC setup. 5. Revisit next week with Remi! 2. [Matt] Booting a kernel… without a bootloader you can interrupt... Two options: 1. option 1: static config per-device, place the files in the right place for the device and start it. depthcharge, or PXE-alike systems. Mostly there, but needs tying together 2. option 2: kea (or similar) - modify the DHCP config (kea?) as the test starts. Really the right answer for PXE infrastructure. Better solution, but longer term 3. [stevanr] Authentication refactoring mr’s are in, Remi will start reviewing after Monday 1. https://git.lavasoftware.org/lava/lava/mergerequests/511 2. https://git.lavasoftware.org/lava/lava/mergerequests/515 3. [Steve] will send out a mail describing our plan to collect together database migrations in future releases, for sanity 4. [deanb] Large job definition causes scheduler to hang. 1. No errors given, I think it’s simply taking a long time to read the definition and create a pipeline 2. (particular example in this test is ~25k lines of job definition, massive amounts of inline test definitions) 3. not clear what's going on? is it just time to parse yaml? using lots of memory for pipeline stuff? 5. [deanb] Reboots during test 1. Team wants to run a test step which sometimes locks up if we don’t reboot occasionaly. 2. Want to run a segment of a test, then reboot, then continue. 1. [milosz] try this : https://github.com/Linaro/ test-definitions/tree/master/automated/android/ noninteractive-tradefed 3. long-time wishlist feature for LAVA, but problematic: 1. how do we make sure the device boots sanely? not all devices are safe here? 2. the test suite will need to checkpoint where it got to, so it can resume sensibly after reboot 6. [deanb] Serial corruption when executing lava test shell 1. Not sure how to handle 2. Get corruption in the string when executing /lava-... 3. Once we’re into the lava test shell, we can run command to turn off kernel logging to avoid this, but cannot if we cannot enter the test shell 4. Multiple UART may solve this. Do test shell on alternate tty or over ssh 7. [deanb] Using long URLs in notify block causes lava-logs to crash 1. Possibly increase db field length 2. Check the length earlier, fail the job, don’t crash lava logs. 3. Could we make this variable length, maybe? 4. Deanb to put an issue in on git.lavasoftware.org

============================================================================

The LAVA design meeting is held weekly, every Wednesday at 13:00 to 14:00 UTC using Google Hangouts Meet: https://meet.google.com/qre-rgen-zwc Feel free to comment here or join us directly in the meeting.

Minutes from this and previous meetings are also stored in the LAVA wiki:

https://git.lavasoftware.org/lava/lava/wikis/design-meetings/index

Cheers,