Hi folks,
We held our regular weekly design meeting yesterday via Hangout. Brief
summary of discussion:
* [Stevan] Further discsion about the permissions model code
+ He followed up on -devel with more details [1]
* [Steve] Sprint - where are we up to?
+ Hanging fire for now, waiting for OK from Linaro management on
budget etc.
[1] https://lists.lavasoftware.org/pipermail/lava-devel/2019-January/000017.html
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
Dear all,
I'd like to propose a couple of designs and thoughts on the
authorization subject and get the feedback from the community and LAVA
core team in the process. Link to the issue:
https://git.lavasoftware.org/lava/lava/issues/201
As stated before, the main reason behind the authorization revamp is
that checking the device types accessible to the specific user is not
optimized in the slightest and does not scale. The specific device type
authorization is in some cases also used in device authorization which
also adds to the complexity.
Now, while the problems at hand can be addressed directly to mitigate
the scalability, it'd be also smart to do something about the
django-restricted-resource library. Why? Well, django already has a
perfectly sound authentication model which can also be used for a
per-object access with a little effort so essentially it means much less
complexity, code and all the benefits that go along with these.
There's two approaches here: write our own authentication backend and
use already existing django-guardian project (available as debian
package) which is well maintained. I think having our own backend is
slightly better solution just because there's no need to add more
complexity with a third-party package then we need and it seems to me
that our needs can be addressed with a small code base.
Once that's in place, the proposal is to address the device-type
authorization with a cached value (currently, if a user can access any
device from a specific device type, it can access the device type as
well), meaning that we store the device-type visibility as a separate
permission automagically so that the check for that can be performed
without checking all the device permission in that device type. We'd
also remove the complexity in the various frontend views regarding the
device/device type visibility without changing the behavior.
All comments/ideas welcome.
Cheers,
--
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs
I replied to Dean on this in an email thread, but thought I’d capture the information in the public forum.
I’ve got a device passthrough script that doesn’t require the docker container to be run in privileged mode: https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts/docker/pas… <https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts/docker/pas…>
I can force a trigger event by setting up an appropriate udev rule, e.g. I have the following in my test rig /etc/udev/rules.d/100-lava-docker.rules:
ACTION=="add", ATTR{serial}=="21F6C6B800314249", RUN+="/root/docker/passthrough -d 21F6C6B800314249 -i lava-dispatcher-01-2018-11"
ACTION=="add", ATTR{serial}=="28B114C800334FA2", RUN+="/root/docker/passthrough -d 28B114C800334FA2 -i lava-dispatcher-02-2018-11"
Once set up, just do:
udevadm control --reload-rules
This will then allow hot plug for fastboot type devices.
My bash script for running up a docker dispatcher is as follows:
#!/bin/bash
set -e
set -x
docker run \
-v /dev/bus/usb:/dev/bus/usb \
-v /dev:/dev \
-v /dev/serial:/dev/serial \
-e "DISPATCHER_HOSTNAME=--hostname=lava-dispatcher-01-2018.11" \
-e "LOGGER_URL=tcp://172.16.1.1:5555 <tcp://172.16.1.1:5555>" \
-e "MASTER_URL=tcp://172.16.1.1:5556 <tcp://172.16.1.1:5556>" \
--net lavanet --ip 172.16.2.1 \
--name lava-dispatcher-01-2018-11 \
-it lavasoftware/amd64-lava-dispatcher:2018.11
With this, static serial type devices will just be available - i.e. Serial devices, Arm Energy Probes etc.
I am in the process of writing start scripts in Python that hides all the nasty work. I actually got this working using the Python docker library yesterday, now working on making it friendly.
(sorry if I’m preaching to the choir here, just trying to give as much info as possible!)
Hope this helps
Dave
----------------
Dave Pigott
LAVA Lab Lead
Linaro Ltd
t: (+44) (0) 1223 400063
Hi folks,
We held our regular weekly design meeting today via Hangout. Brief
summary of discussion:
* [Stevan] Publish the sprint topics to the -devel mailing list?
+ Will do once we have the new date worked out
* [Stevan] Access rights code investigation
+ He'll follow up on -devel with more details
* [Dean B] Post about the docker passthrough stuff on -devel
+ Just happened - see
https://lists.lavasoftware.org/pipermail/lava-devel/2019-January/000010.html
* [Steve] 2019.1 Release planned for Thu 24th
+ Rémi and Steve doing the release, Neil advising/observing
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
Dear All,
We've been looking into running some lava dispatchers in containers from
the official lava dispatcher images, and we've been running into issues
when interfacing these with real DUTs.
This is mostly to do with USB passthrough from the physical server to the
dispatcher container. Without any USB device passthrough, lava cannot
interface with the DUT.
We are under the impression there is some scripts or code (which may still
be a work in progress) that may help us with this situation. We're
wondering if we can get our hands on this and test this against our devices
and see if it covers all our use cases.
Our use cases include a mix of static devices (present all the time),
dynamic devices (only present under some circumstances, like the DUT is
powered on). We also have cases where the device will be present on job
startup, but renumerates on certain conditions, which means we may need to
combine techniques for static and dynamic devices. We'd also like to test
different usages of these devices within containers after the passthrough
happens to check that each bit of tooling can work correctly
(adb/fastboot/mounting filesystems/etc).
Thanks,
Dean
Hi folks,
We held our regular weekly design meeting today via Hangout. Brief
summary of discussion:
* LAVA 2019.01 release
+ Tentatively planned for 24th January
+ Neil normally does the functional release tests, may need to take
those over if he's still ill.
+ What should be included?
Quick discussion of open Merge Requests:
- !336 Milosz still testing
- !333 - merge, looks good
- !331 - merge, definitely needed
- !328 - looks good
- !324 - needs review
- !323, !321 will wait
- !309 - check and review
- !302 - review
- !295 will wait for discussion
- !294 needs more work
* BKK19 presentations?
+ lavafed/meta-lava
"LAVA community enabled testing"
+ LAVA user forum
Already requested
+ Bootloader testing (with Loïc Poulain)
Would be great
* Inviting community to the design meeting?
+ We've been talking about doing this for a while, but never
actually got round to it. It's time we did! See below for
details.
+ Agreed to send mail to lava-devel each week with summary of the
minutes, with a link to the HO for the meeting itself [Steve]
+ Mail to -announce describing this [Steve]
+ If we ever overflow what hangouts will deal with, worry about it
then
+ If we ever need private meetings, we can have those as needed
* Access rights improvement
Stevan is looking into revamping how access controls are
implemented, to make things simpler/cleaner/faster. He'll add a
ticket at git.lavasoftware.org and mail the -devel list with more
details.
* Decoupling scheduler from the frontend
We were planning on discussing this at the sprint this week before
it was postponed. Hoping to re-organise it soon...
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
https://fosdem.org/2019/
(No registration is necessary for FOSDEM - if you can get to Brussels,
you are welcome to just turn up on site. Avoid trying to park near the
site unless you get there very early, use public transport.)
https://fosdem.org/2019/practical/https://fosdem.org/2019/stands/
If you haven't been to FOSDEM before, note that there will be a huge
number of people attending FOSDEM (well over 8,000 are expected), so
the only real chance of meeting up is to have a known meeting point.
Hopefully, you'll have a chance to get to some of the 700 sessions
which have been arranged over the 2 days.
Linaro will have a stand at FOSDEM 2019 in the AW building. The stand
will be on the ground floor, along the corridor from AW120 near
MicroPython and PINE64. Various Linaro and LAVA people will be around
the stand during the event, so this can act as a focal point for
anyone wanting to talk about Linaro and or LAVA during FOSDEM.
https://fosdem.org/2019/schedule/room/aw1120/
The AW building is near the car park, across from Janson and the H building.
Various Linaro and LAVA people have been routinely attending FOSDEM
for a number of years. If you are able to get there, we will be happy
to see you.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Dear Lava Dev team,
I cloned the LAVA source from git@github.com:Linaro/lava.git and able to build. From the said repo, I dont get "lavacli", "lava-coordinator" and "lavapdu-daemon".
Please provide more information on source repos and build procedure.
Thank you,
-Yash
