Hi folks,
We held our regular weekly design meeting today via Hangout. Summary
of brief discussion:
29th May 2019
1. [Rémi] 2019.05 release: changelog
1. Last part of the fix for the security issue regarding job
context
2. Lava-slave and socks proxy for remote labs behind proxies
3. Compressing job logs
2. [Rémi] Next releases
1. 2019.06
1. Rest api filter
2. device dictionary access from the test shell
2. 2019.08
1. auth refactoring
3. [Steve] Name for the extra udev tools package?
1. Forwarding udev events to docker containers
2. udev pass-through script
3. "docker-udev-tools" agreed and created as a new project
1. https://git.lavasoftware.org/lava/docker-udev-tools
============================================================================
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,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hi folks,
We held our regular weekly design meeting on 22nd May via Hangout. Summary
of brief discussion:
22nd May 2019
1. [milosz] How to fix packaging on this branch: https://
git.lavasoftware.org/mwasilew/lava/pipelines/3220 ?
1. Fixed by Steve and Rémi
2. Problem with some debian python packages
2. [Steve] charfield to textfield changes needing work - !527
1. as Stevan points out, this is breaking other things.
2. Going to back out the future-proofing changes that extended
this, and go back to just fixing the specific things that we've
found to be broken
3. [stevanr] Auth refactoring submit/resubmit/cancel permissions
1. Currently: submit is a separate permission and resubmit/cancel
goes in the same permission level
2. Submit permission is not tied to specific testjob while
resubmit and cancel are
3. [ivoire] Keep things as is
4. [Anibal] questions about the fastboot-nfs setup - how to do things?
1. how to pass information into the lxc when creating the image?
2. Ordering of actions is important - the test action in the lxc
will need information that's available from the fastboot deploy
step. To pass via overlay, would need this to be available
before the lxc deploy
3. Can we simply pass the device dict for the DUT into the lxc,
similarly to what Tim has in https://git.lavasoftware.org/lava/
lava/merge_requests/536 ?
4. How to list the variables/information we want to have
available?
1. Device dictionary
2. Some dynamic data (nfsrootfs address)
5. What about listing in the test block, the “dependencies” (find
a better name) that we are expecting?
============================================================================
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,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hi folks,
We held our regular weekly design meeting today via Hangout. Summary
of brief discussion:
15th May 2019
1. [Steve] https://git.lavasoftware.org/lava/lava/issues/273 - Using long URLs
in notify block causes lava-logs to crash.
1. Clearly using the wrong type of field here (fixed-length CharField
instead of an open-length TextField). That's easily fixed.
2. Where else might we be using the wrong data types in our DB models and
potentially storing up future bugs? Quick scan of CharField uses in
models.py:
1. ExtendedUser.irchandle 40
2. ExtendedUser.ircserver 40
3. Architecture 100 (primary key)
4. ProcessorFamily 100 (primary key)
5. Alias 200 (primary key) (also, ignoring due to other work)
6. Core 100 (primary key)
7. DeviceType.cpumodel 100 (primary key)
8. Worker.hostname 200 (primary key)
9. Device.hostname 200 (primary key)
10. Device.deviceversion 200
11. JobFailureTag.name 256
12. TestJob.subid 200
13. TestJob.targetgroup 64
14. TestJob.description 200
15. Notification.template 50
16. Notification.blacklist 100 (array)
17. Notification.queryname 1024
18. Notification.conditions 400
19. NotificationRecipient.email 100
20. NotificationRecipient.irchandle 40
21. NotificationRecipient.irc_server 40
22. NotificationCallback.url 200
23. NotificationCallback.token 200
2. [Remi] udev event forward
1. How to get udev events (kernel and udev types) inside a docker
container?
2. The NETLINK socket is affected by the network namespaces
1. Run systemd-udev inside the docker container
2. Remove the network namespace (--net host)
1. Ugly and hacky
3. Run a service on the host that forward events
1. Another project on lavasoftware.org - udevforward.py
2. [Rémi] sending to all docker containers? Filtering the
container names?
1. Currently broadcasting to the selected containers only.
3. [Rémi] Make udevforward a proper project under the lava group
1. [All] find a good name, let’s chat on irc
2. Will move the passthrough script in the same repo.
3. [Kumar] Race between Cortex-M USB devices and Connectdevice()
1. Some boards: 1 usb for serial + debug/flashing
2. udev event for the tty vs symlink created
3. [Kumar] create an issue in git.l.o/lava/lava
4. [Matt] lava-test-raise allow different exceptions
1. Parsing args on device vs parsing args on server
1. Parsing on the DUT is cleaner
2. [Matt] finish the patch and send a MR
5. [Dan] Support fastboot boot with ramdisk and NFS issue 271
1. Mimic uboot, command ramdisk or command nfs
2. Maybe something like https://staging.validation.linaro.org/scheduler/
job/252683/definition#defline39
6. [Dean] Job error spotted with message “Unable to create metadata store:
[Errno 36] File name too long: '/var/lib/lava-server/default/media/
job-output/2019/05/15/61270/metadata/…”
1. How to safely truncate these filenames and still save them?
2. Check this isn’t multiple lines and test cases etc.
3. [Dean] to raise a bug with some more info
7. [Rémi] Cycle planning draft
1. -ENOTIME, coming back to this later
============================================================================
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,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
> On May 9, 2019, at 8:11 AM, Kumar Gala <kumar.gala(a)linaro.org> wrote:
>
> In trying to run lava-dispatcher inside a docker container and connect a FRDM-K64F board ran into some issues related to the fact that udev events aren’t seen inside the container since we aren’t typically running systemd/udevd there.
>
> I came across this project that will forward udev events from the host to a container that worked pretty well:
>
> https://github.com/eiz/udevfw
>
> I’ve re-implemented this in python for easier development (added some docker awareness):
>
> https://git.lavasoftware.org/galak/docker-compose/blob/lite/contrib/udev-fo…
>
> Right now running udev-forward.py is kinda kludgy. Wanted to get input on how people think this should work, should we make a daemon out of it? Should there be some kinda of config file? Do we think we need to filter events (and if so how)? Need to look at support for multicasting (support sending to multiple dispatchers). Where should this live, in docker-compose repo?
>
> Other thoughts.
>
> - k
I’ve updated my udev-forward.py script to handle multicasting and handle the lifecycle of docker containers better (having them come up/down, already be running).
Now its much closer to being able to run just as a deamon, still need to figure out how we’d specify config info for that case.
- k
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,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hi!
Anibal and I put together a list of steps that can be used to 'fastboot
boot' to a ramdisk or nfs root filesystem in LAVA issue 271[1]. The idea
here is to have LAVA create a boot image at runtime based on a kernel,
kernel modules, optional ramdisk, and a dtb file. Embedded in the boot
image is the kernel command line necessary to boot to a ramdisk or to an
nfs root filesystem. This boot image is then run with 'fastboot boot'
directly - no flashing required.
This is based on discussions related to dragonboard-845 implementation,
and would make such boards compatible with kernelci (for example), but
also simplify kernel test jobs that don't require a system image to be
flashed to the board.
We started to look at what would be needed on the LAVA side to implement
this, but need help defining the semantics and requirements for the LAVA
implementation. I'm also not sure which parts should be in an LXC/docker
type context, and which parts should be directly supported in LAVA. I
can imagine the rest of the semantics will be very similar or the same
to the tftp deploy type.
Feedback and LAVA implementation suggestions welcome. Perhaps this can
be a topic at the next LAVA design meeting (can I get an invite?).
Thanks,
Dan
[1] https://git.lavasoftware.org/lava/lava/issues/271
