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
