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
Hi,
There is an idea of device type 'alias' in LAVA. I don't quite
understand what the use case for the current implementation was [1]. I
tried using it but it wasn't very useful. My use case is that I need
to submit jobs to a device type with different device type name. This
is used to align device type naming between different labs in a bigger
project (kernelci.org in this case). So the questions I have about
current implementation:
- is there anyone using current implementation?
- if current implementation is used, how much trouble would it cause
to change the behaviour?
Change in behaviour is quite intrusive and will require database migration.
[1] https://master.lavasoftware.org/static/docs/v2/glossary.html#term-alias
Regards,
milosz
Hi folks,
We held our regular weekly design meeting today via Hangout. Summary
of brief discussion:
## lava-lxc-mocker + db845 booting kernel/dtb/modules [Matt]
* Kevin and Matt: how to change binaries before flashing with fastboot?
* Should be possible using lxc and lxc://
* See [lxc-sdm845-mtp-test](https://validation.linaro.org/scheduler/job/1912316/de…
* Kevin: issue with lava-lxc-mocker inside docker container
* [Milosz] Working for [lavasoftware/lava-dispatcher](https://hub.docker.com/u/lavasoftware/lava-di… docker image
* Kevin to compare his docker container to lavasoftware/lava-dispatcher
## Replacing lxc protocol by docker (without protocol) [Rémi]
* New feature for the near future
* Allow for simple deploy.fastboot and boot.adb actions
* No need for lxc protocol anymore
* With the option (per job) to use a custom docker container
## u-boot commands: nfs vs ramdisk [Rémi]
* After [!467](https://git.lavasoftware.org/lava/lava/merge_requests/467), u-boot jobs booting from nfs without a ramdisk are failing. See [meta-lava](https://git.lavasoftware.org/lava/meta-lava/-/jobs/38813).
* [!492](https://git.lavasoftware.org/lava/lava/merge_requests/492) fixes this but breaks [cubietruck](https://federation.lavasoftware.org/lava/scheduler/job/361)
* Jobs using both ramdisk and nfs will fail (every job booting debian)
* Adding a new command: "ramdisk-nfs"
## lavafed and KCI [Rémi]
* Presenting lavafed
* [Kevin] will this be a problem with multiple dispatchers?
* [Rémi] lavafed will see the lab as many sub-labs (one per dispatcher)
* [Kevin] is it possible with docker dispatchers?
* [Rémi] yes. Install docker-cli and bnd the docker socket in the container. LAVA will then be able to call docker run from inside the container.
Rémi to send a mail with the details to kevin
## 2019.04 release [Rémi]
* When do we release?
* Next Monday
* What can be moved to the next release?
* See GitLab milestone
## REST API filtering - issue with package dependencies [Milosz]
* [failing pipeline](https://git.lavasoftware.org/mwasilew/lava/pipelines/3220)
* Looks like a problem when building the debian package
* Steve to look at it.
============================================================================
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 discussion:
1. JS and CSS minifications [Rémi]
* Is minification really useful?
* Make building more complex
* Make debugging difficult
* Add potential failures (bugs in the compiler)
* Does minify save a lot of bandwidth?
If the resources are compressed (using gzip or brotli) then the gain is not
significant and not worth the effort.
Sounds better to remove the minified version and ensure that the server
only send compressed versions whenever possible.
2. ramdisk vs nfs boot in u-boot [Rémi]
Some jobs (like [cubietruck](
https://staging.validation.linaro.org/scheduler/job/251164/definition))
provide both a ramdisk and an nfsrootfs while booting with nfs commands.
* Is the ramdisk of any use?
* Is it possible to remove the command that loads the ramdisk completely?
Dean to look at the jobs ARM ran to see any use of this.
============================================================================
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,
--
Rémi Duraffort
LAVA Team, Linaro
Dear LAVA team,
in my LAVA setup I need to connect my DUTs to certain interfaces on the worker. The information which of my DUTs is connected to which interface has to be available in my test shell somehow. The documentation gives the impression that LAVA is capable of this:
https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highligh…
It says: "Other static devices which are accessible over the network can be made available to a test shell in the LXC through lava test shell helpers".
Browsing through the code shows that this is implemented only for one single use-case, though, that is energy probes (via helpers "lava-probe-ip" and "lava-probe-channel"). There does not seem to be any generic mechanism to make static device info available in the test shell. The documentation is quite misleading here in my opinion, since it does not reflect the actual implementation.
I have asked about this on the lava-users mailing list, and Neil confirmed my investigation:
https://lists.lavasoftware.org/pipermail/lava-users/2019-March/001741.html
He answered my question, whether there is a generic mechanism to supply static_info from the device dictionary in the LAVA test shell, with "Not currently".
Is such a feature planned? If not, would you accept code contributions which add such a feature?
I actually do not see why the two helpers for the energy probes have been hard-coded in the first place. Why hasn't this been implemented in a generic way from the beginning?
In my idea, there would be only one single function "lava-static-info" which outputs the complete static info array in some form. The caller can then extract the info he needs from there. Is there any reason against such an extension?
Alternatively, are there any other suggestions on how to implement my use case? To make it clear once again: I have four USB-RS232 converters, available on the worker as /dev/ttyUSB0 to /dev/tty/USB3. I have four DUTs, each of which is connected to one of the converters. The test shell has to know which of the TTY devices to use for the test, depending on the actual DUT chosen by the LAVA scheduler.
Hope to get some useful replies here. Thanks in advance.
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi folks,
We held our regular weekly design meeting today via Hangout. Summary
of brief discussion:
1. [Steve] Connect sessions planning
1. Bootloader testing
2. lavafed
3. users forum
As lots of us will be at Connect this coming week, the design meeting
for 3rd April will not be happening via Hangout.
============================================================================
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 discussion:
1. [Rémi] cycle planning
1. better at Connect?
2. we should make sure that all things are discussed/mentioned on
the -devel list before we start them
2. [Steve] Connect sessions
1. Bootloader testing
2. lavafed
3. users forum
1. Slides about last features and planned work for next 6m
3. Debian backports updates
1. More desired python modules uploaded into backports
2. lavacli 0.9.5 shortly
============================================================================
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
