Hi folks,
We held our regular design meeting today via Hangout. Summary of brief
discussion:
# 11th September 2019
# Reducing the privilege of lava-slave [Antonio]
It’s more or less ok that lava-run requires being run as root. But can we
run lava-slave as non-root?
Lava-slave needs to cleanup after lava-run if something goes wrong, so
there might be stuff owned by root left over and this needs to be handled.
Otherwise it’s `go for it`.
# Replacing LXC with docker [Antonio]
How exactly do we want to do that: See
https://git.lavasoftware.org/lava/lava/issues/305 and
https://git.lavasoftware.org/lava/lava/issues/286
The goal is to:
* simplify the job definition (see the job definition in
https://git.lavasoftware.org/lava/lava/issues/305)
* allow to use user provided docker container to run adb
# Job level privileges [milosz]
How does that work compared to device and device-type level privileges?
See https://git.lavasoftware.org/lava/lava/merge_requests/693 for more
documentation
The job level permission are still applied, but the device-type and device
permissions are also applied (was not the case before).
# LAVA package uploads to Debian? [Steve]
I don't have time to do it anymore, and we have RC bugs:
* some django2 issues too? patches from Antonio
* One more patch https://git.lavasoftware.org/lava/lava/merge_requests/696
* Gunicorn problem? Need to update the dependency
* VLANd python3 conversion underway
* lava-coordinator debian package depends on python2
# New maintainer for vland [milosz]
Since Steve is moving to a new project we’ll need a new maintainer for
vland.
# SAN19 - all stuff up to date and slides done? [Steve]
Any meetings to plan?
* lavafed
# Moving docker base images to buster? [Rémi]
When should we use buster as the base image?
Will be the base image for 2019.10
# Hangout meetings links changed [Steve]
The documentation should be updated.
============================================================================
The LAVA design meeting is held weekly, every Wednesday at 13:00 to
14:00 UTC using Google Hangouts Meet: https://meet.google.com/usu-aatj-fht
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
Hi Remi,
When I was doing the lkft upgrade this morning I noticed that there is a Buster dependency for LAVA. One of the workers had somehow been missed out on the Buster upgrade and was still on Stretch. I discovered the following:
lava-dispatcher : Depends: python3-requests (>= 2.20.0) but 2.12.4-1 is to be installed
Does this mean we really have to check for Debian version 10.0 or later for remote, bare metal, workers?
Thanks
Dave
----------------
Dave Pigott
LAVA Lab Lead
Linaro Ltd
t: (+44) (0) 1223 400063
Hi folks,
We held our regular design meeting today via Hangout. Summary of brief
discussion:
# 31st July 2019
# Using celery inside LAVA [Rémi]
Could be used for:
* Parsing description.yaml
* Replace crontabs
* Compressing logs
* Removing old jobs
* Sending logs to ES
* Splitting scheduling
* notifications
# August release ? [Steve]
Yes - aim for 28th
The release will have database changes
Tag the day before to let some time for lavafed to test the tag
# LAVA sessions for Connect [Steve]
Three sessions has been accepeted:
* LAVA Users' Forum
* Hacking and contributing to LAVA
* Advanced testing in python
# Support packages in Debian removed/being removed [Steve]
* lava-tool removed (https://tracker.debian.org/pkg/lava-tool)
* django-compat marked for removal (
https://tracker.debian.org/pkg/django-compat)
* django-hijack depends on django-compat, marked for removal too (
https://tracker.debian.org/pkg/django-hijack)
* Rémi will remove the dependency/mention
* VLANd needs some rework to go to [python 3](
https://git.lavasoftware.org/lava/vland/issues/5)
# Migrating to django 2.2 (next LTS release) [Milosz]
* lava source code itself is compatible with django 2.2
* Dependencies on filters and rest framework
* Still waiting for a release compatible with django 2.0
* Trying to contact the maintainer to give some help (if needed)
# gitlab-runner on aarch64 [Steve]
The current package in [Debian](
https://tracker.debian.org/pkg/gitlab-ci-multi-runner) was a bit too old.
GitLab don't provide anything for arm64 but the Debian maintainer uploaded
a new version that fixe our issues.
============================================================================
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
Hi folks,
We held our regular design meeting today via Hangout. Summary of brief
discussion:
# 24th July 2019
# install.git-deps [milosz]
This feature works nicely:
https://lkft.validation.linaro.org/scheduler/job/834097
Proposal: keep `install` option but restrict it so it’s not trying to
install system packages.
[Rémi] Will submit a patch to remove the “deprecation” warning in the
documentation.
# Authentication refactoring [milosz]
Under review by Remi. Looks good.
# Connect sessions where accepted [Rémi]
* LAVA users forum
* Hacking and contributing to LAVA
* Advanced testing in python
# Playing with Sentry error reporting [Rémi]
* Will create a ticket to have it installed in the linaro lab.
* Will create sentry.lavasoftware.org
* No debian package available for python3-sentry-sdk
* Should be installed from pip (sentry-sdk)
* Will send a patch to install sentry-sdk from pip in lava-server docker
container.
* Activate it for lavafed instances.
============================================================================
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
Hi folks,
We held our regular design meeting today via Hangout. Summary of
brief discussion:
# 17th July 2019
# Large job definitions causing outages [deanb]
* Issue: https://git.lavasoftware.org/lava/lava/issues/299
* Wondering if for large jobs (configurable limit) simply not making
ActionData objects is a sensible approach.
* Tried this:
https://git.lavasoftware.org/dean-birch/lava/commit/dd220c0bd82bf092e35e643…
* In my test instance this reduced outage to 30 seconds (from hours).
* If not, what else can we do?
* Anything extra needs to be added?
* Documentation?
* [deanb] will send a patch with the first improvements (CLoader)
* [deanb] will look at using bulk save to save all objects in one call
* [stevan] investigate ActionData: is it possible to create them later on
or even maybe not creating them?
# Test from inline with git [milosz]
The idea is to source test-definition YAML from inline but use git
repository to prepare overlay. Example: https://github.com/andersson/bootrr
Bjorn doesn’t want to have YAML file in this repository
[Rémi] Using install.git-repos might work
*
https://git.lavasoftware.org/lava/lava/blob/master/lava_dispatcher/tests/te…
*
https://docs.lavasoftware.org/lava/lava_test_shell.html#adding-git-bzr-repo…
[milosz] will try install.git-repos
If that’s working Rémi will add some tests in lavafed or meta-lava
# Switching between serial connections on device with multiple UARTs
[Malcolm Brooks]
* Issue: We have devices which use separate serial outputs for MCC, AP and
SCP UARTs.
* Workaround: Use the `new_connection` boot method to switch between UART1
and UART2 in order to catch the kernel booting once MCC flash stage is
complete.
* Idea: Allow all connections (or possibly a subset defined in the
“connection_tags” for example) to be established and followed from the
beginning of the job, and allow each action/stage to select which they are
actually listening/interacting with the `connection` option (example below).
```yaml
- boot:
namespace: target
connection: uart1
method: minimal
```
[Rémi] Sounds like a good idea.
* Using feedback LAVA can already use one connection and listen/print the
other ones
* Malcom will create an issue on gitlab.
============================================================================
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
Hi All,
We've previously had an issue on our LAVA instance where it stopped
responding to workers and stopped dispatching jobs when it finished running
large job definition (around 25000 lines in the definition, around 1000
deploy/boot/test actions). I've been looking into reproducing this safely
in a development environment, and I've got a few observations and questions
about how the situation could be improved.
The lava-master process appears be stuck processing the job results, and
takes a painstakingly long time to finish this and send an ACK for END_OK.
During this processing, the master doesn't respond to worker pings, and
doesn't schedule other jobs. Tracking a bit deeper, it seems that the vast
majority of time (I've never seen it finish as I have always restarted the
lava services before it finishes) in the walk_actions and build_action
functions of the lava_results_app/dbutils.py file:
https://git.lavasoftware.org/lava/lava/blob/2019.05.post1/lava_results_app/…https://git.lavasoftware.org/lava/lava/blob/2019.05.post1/lava_results_app/…
What options is there to mitigate this issue? Some ideas below:
- Could we optimize the build_action function? There are a few Django
model/db queries in build_action, could some results be queried once and
cached? With an obscenely large job, would this even give us enough savings
to make the time invested in safely optimizing this worth it?
- What are the implications of not having created ActionData objects for a
job? Does this mean that no options will be available in the "Pipeline ↓"
drop-down on the job page for quick navigation? Could we optionally abort
after a certain amount of these (and make it configurable per LAVA
instance)?
- Should/could the handling of the results be forked off, so lava-master
can continue to schedule more jobs and respond to worker pings, but slowly
the ActionData objects can be populated? I'm unsure if you have to be on a
special thread to write to Django models. Even if this could be done, would
any weird behaviours occur on the slave side as it will still be waiting
for the ACK for END_OK from the master?
Any guidance on how to proceed with this would be appreciated! I'm happy to
place this and some more details in as a LAVA issue on git.lavasoftware.org
if this is easier to track and discuss.
Thanks,
Dean
Hi folks,
As Rémi and Stevan are both out and we don't have any items listed for
discussion in advance, I'm cancelling today's design meeting.
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 design meeting today via Hangout. Summary of brief
discussion:
3rd July 2019
1. [Rémi] 2019.07 release?
1. Should we do one?
2. Most people will be out for most of the month
3. Maybe worth it for the LITE group (depends on the number of
patches).
4. Steve back from DebConf on the 28th, but…
5. Yes: releasing around the 18th
2. [Rémi] Debian buster is due soon
1. Basing the docker image on Buster?
2. No, wait for a little bit. Maybe 2019.08?
3. Staging is already running Buster, main v.l.o is still on Stretch
but the lab team will want to upgrade soon
4. How long do we support stretch-backports?
5. Add buster-backports soon, as new uploads will hit Debian
unstable (---> Bullseye).
6. Target 2019.08 at all three releases (stretch-backports,
buster-backports, bullseye)
3. [Rémi] Recommendations about VACUUM ANALYZE
1. This should be run regularly (every day) on busy instances to
clean up
2. Add a thing in the docs, test in the lab
3. See https://www.postgresql.org/docs/11/sql-vacuum.html for more
info - does a VACUUM then ANALYZE without the old data.
4. Lets the DB self-optimise for performance
4. [Rémi] Using git submodule to include docker sources into lava
sources
1. Still a separate repository
2. The exact commit hash used for the lava docker image is now known
and reproducible.
1. This is the main reason
2. Using version.py on the last commit of the docker directory
can also work.
3. See https://git.lavasoftware.org/lava/lava/merge_requests/637
4. Let's go with this instead of git submodule, it works fine
============================================================================
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 design meeting today via Hangout. Summary of brief
discussion:
26th June 2019
1. 2019.06 release
1. https://federation.lavasoftware.org/versions/
2019.05.0050.gf287c3449/
1. Looks ok
2. https://git.lavasoftware.org/groups/lava/-/merge
requests?milestonetitle=2019.06
2. [Dean] Fast model support
1. Was deprecated 2 years ago with V1
2. Now needed again
3. Run as a user-configured container (so test writer does
stuff), or re-integrate like we had with v1?
4. Very similar to how we do qemu
5. Look at how we run openocd/gdb as inspiration
3. [Remi] Allowing test job definitions to override U-Boot
config (e.g. load addresses)
1. Should be easy, waiting on a patch from Matt
4. [Kumar] Direct serial connection (#296)
1. pyserial probably the best bet?
1. Look at connection tags like in:
1. https://staging.validation.linaro.org/scheduler/
device/staging-black01/devicedict#defline77
2. ser2net works, but this might add more flexibility
3. possible timing problems with ser2net in a container?
4. we can help working out package dependencies etc. if
needed
5. Linaro Connect SAN19 - what sessions should we have?
1. Talk next week, suggestions welcome
============================================================================
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:
5th June 2019
1. [Rémi] 2019.06 planning:
1. Features and issues that should be in for 2019.06
2. Try to assign some, depending on the available time to work
on LAVA
3. [stevanr]
1. VAC, plus auth refactoring fixes
4. [Steve]
1. lots of doc updates
2. debugging some Arm issues
3. vland - docs, new switch support, etc.
5. Finish reviewing/reworking/merging Tim's device-dict in test
job patch
1. Anibal looking into this too
2. With expansion, helps to support the expanded fastboot
image work
6. https://git.lavasoftware.org/lava/lava/issues/277 - make
table lengths configurable?
2. [Anibal] Some NFS code is duplicated - will open an issue
============================================================================
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:
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
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
Hi folks,
We held our regular weekly design meeting today via Hangout. Summary
of discussion:
1. [Rémi] Feature flags (https://martinfowler.com/articles/
feature-toggles.html)
1. Useful for:
1. Schema validator deployment
2. MultiNode on/off for multiple parallel schedulers
3. Store logs in filesystem or ES
4. Other use cases?
2. Per-user or per-instance?
1. Per-instance:
1. Simpler
2. Cover most usages
3. Quicker to implement
2. [milosz] device type alias
1. Does anyone know if it’s used anywhere in the current form?
2. The request from KernelCI/LKFT is to have alias for device type
that can be used in submissions so we can resolve conflicts in
naming schemes between labs
3. ACTION: Milosz to ask about it in the ML
3. [milosz] JS/CSS in the current master doesn’t work for me. Links in
the top bar do nothing. Is this my setup issue or some general
problem?
1. There was a missing link to bootstrap-3.4.1.min.js. I guess this
is my Lsetup issue
2. File is present in lava-server docker image
1. Looks like a local issue
4. [Steve] docs.lavasoftware.org is online, with no content at the
moment
1. /lava, /lavacli, /vland - any others, shout!
2. just going to have the last released version available; if people
complain we can revisit
5. [Dean] Feasibility of targeting specific devices in job definition
1. We are getting asked if this is possible frequently.
1. Why?
2. Currently have to put a tag on with the device name on each
device if this is required, which is not ideal.
3. Really don't want to do this - this was a deliberate change from
v1 to v2. Would need to make modifications to the scheduler to
allow it. Tags are the right answer!
6. [Dean] Question about docker device type. Is there a download action/
deploy step that can be used on a docker to download extra binaries
into the container in the lava definition, then proceed to the test
step which can use those binaries?
1. There isn't, no - use the test shell
7. [Fathi] Alpine based dispatcher and server images
1. How to test those images in the CI pipeline?
1. How often do we test ?
2. Do we build/publish the docker images?
3. [Steve] Very little context on this - what/why/when/where etc.
needed
4. Can we get Fathi to come to next week's meeting and talk about
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. [stevanr] LAVA auth revamp
1. Restricted for authenticated users use case
1. With current design, everything should be open (visible
permission) by default; user, group, is_public fields removed
and permissions assigned by groups
1. [dean] would be useful to restrict to only authenticated
or per group devices/testjobs
2. So if someone wants to restrict visibility to let’say only
authenticated users, it’s a bit tricky to support it with the
current design
2. Device owner
1. My plan is to remove every way of having some arbitrary field
mess with authorization other then permissions. Does anyone
see a problem with removing this field? (physical_owner will
still remain in place but it has no say in auth)
1. [Steve] Check with Dave?
2. Do they use device owner?
3. [Rémi] how to allow one group to update one device object?
1. Is it of any use?
4. [Rémi] code/design/schema available somewhere?
2. [Steve] Future plans - when/how/where do we notify of upcoming
changes?
1. lava-devel by default for most things
2. lava-announce for breaking changes, and give notice
1. how much notice?
1. 1m? 3m? agree on 2 months for things like BD migrations
2. 2019.05 will have some migrations, then no more yet planned
until .08 or .09
3. [Steve] When will schema validation become rigid? .08 or .09 as well?
1. Print warnings before then
2. Schema validation in strict mode will complain about most jobs
(80%?), so we can't turn that on!
3. For now, allow submissions. Also run the validator again in
strict mode and print its output as a warning on submission. Can
we put the same output into the test log too? Should we?
1. Some users may look at the LAVA job results page
2. Some may just grab the logs
3. Maybe start mailing admins with a daily summary of warnings?
Add a management command to check for warnings.
4. Talk to other people (e.g. Matt about kernelci)
4. Maybe look into versioning of schemas and support validation of
supported versions? Lots of work… :-/
5. Not complete yet, we still want people running schema checks and
letting us know about any problems found
1. lavacli jobs validate <job-def.yaml>
2. share/lava-schema.py job <job-def.yaml>
4. [Rémi] doc canonicalization
1. https://moz.com/learn/seo/canonicalization
2. Add links back to https://docs.lavasoftware.org/lava in our help
information
3. Need to get docs.ls.o set up!
5. [Steve] Stevan being added as a reviewer/admin
1. Sort out details offline
============================================================================
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 yesterday via
Hangout. Summary of discussion:
1. [Neil] Job action timeouts
a. Downgrade current change to not reject XMLRPC API job submission [Rémi]
1. lots of jobs on LKFT need changes, likely to be indicative
of a wider problem
b. Implement the XMLRPC check and get lava-schema.py out to
people in 2019.02 [Rémi]
c. Announce the new schema
d. Leave fatal exceptions until a future release
e. Confirmed. the schema validation itself is not yet part of lava_scheduler_app submit.
2. [Neil] Aarch64 gitlab-runners
a. Initial config available, needs optimisation, especially
concurrency per machine vs cores per runner
1. optimisation to be done during 2019.03 cycle.
b. [Steve] Mustang machine not booting - investigating
1. could be an issue with upgrade to buster.
3. [Neil] wisdom of running unit tests inside docker builds in the
ci-images project?
a. guarantees that the new image won't break lava.git master.
b. another item to be added to the docs of how our CI
operates. [Neil] needs an issue.
4. [Neil] Remi to authenticate the GnuPG fingerprint for
4E9995EC67B6560E0A9B97A9597DCC10C0D1B33D to enable lavasoftware.org
ansible password_store
a. Now fixed via keys.gnupg.net and pgp.earth.li
5. [Dean] Feasibility of upgrading django-ldap-auth to version 1.7?
a. https://tracker.debian.org/pkg/django-auth-ldap
b. To sync LDAP groups into Django auth.
c. We want to be able to mirror LDAP groups as groups in LAVA
(details of this:
https://django-auth-ldap.readthedocs.io/en/latest/permissions.html#group-mi…)
but examples of this given in 1.5 docs (oldest I've found) don't
appear to work in 1.3
d. I believe 1.7 is in Buster, so is it a case of moving to buster?
1. not urgent to migrate to buster now.
6. [Steve] location for documentation
a. Needs an issue to track this.
1. avoid the rabbit hole of optimising what is left.
b. certain elements need to go into the website from lava-server-doc
1. Release docs
2. Development process
3. Design overview
4. Keep development-intro and update links.
c. update all the links in lava-server-doc.
d. website will move to Sphinx instead of Pelican.
e. a lot of docs are using Sphinx RST.
1. there will be some conversion needed for items which are currently in Google Docs.
f. move design meeting doc to the wiki?
1. no - interactive shared-editing feature is very useful
2. we can simply copy text to the wiki after the fact
3. Page per meeting in the wiki with index links
4. Consider the new document as public by the end of the meeting.
7. [Remi] MuxPi rPi zero. build raw images.
a. Guestfish based on GuestFS
b. inside docker? need /boot and /lib/modules volumes. Easy scriptable
way to do things.
c. Should we publish our images and a way to rebuild them?
1. Let's not do this as an automated public build
a. Neil to close https://git.lavasoftware.org/lava/functional-tests/issues/7 (Use
GitLab CI to auto-build functional test image files for
files.lavasoftware.org) on the basis that we are not an image
building service.
2. Must document how our images are built
a. files.lavasoftware.org already includes copies of the
scripts which were used to create the Debian standard image files.
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.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
