On 26 April 2018 at 10:26, Conrad Djedjebi <conrad.djedjebi(a)linaro.org>
wrote:
> Good morning everyone,
>
Changing to the lava-users mailing list.
>
> I am looking for some advice with the LAVA Scheduler App.
> I noticed the file /etc/lava-server/settings.conf is not allowing users to
> activate debug messages from the LAVA Scheduler App.
>
settings.conf is for Django settings (which includes support for DEBUG =
True) and that can be enabled on any development instance.
There is also the django-toolbar which can be used for UI work.
https://staging.validation.linaro.org/static/docs/v2/debian.html#debugging-…
>
> Is there a way to activate debug messages in LAVA Scheduler App? If it is
> the case, which file shall I edit?
>
> In the file /lava_scheduler_app/models.py for instance, some loggers are
> being called. However, their outputs are not appearing during the job
> process.
>
logging goes into the lava-master logs typically.
Django exceptions go into the django.log
There is more on this in the documentation.
https://staging.validation.linaro.org/static/docs/v2/development.html#devel…https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html#de…
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi all,
I've encountered a deadlock in my LAVA server with the following scheme.
I have an at91rm9200ek in my lab that got submitted a lot of multi-node
jobs requesting an other "board" (a laptop of type dummy-ssh).
All of my other boards in the lab have received the same multi-node jobs
requesting the same and only laptop.
I had to take the at91rm9200ek out of the lab because it was behaving.
However, LAVA is still scheduling multi-node jobs on the laptop which
requires the at91rm9200ek as the other part of the job, while its status
is clearly Maintenance.
Now, until I put the at91rm9200ek back in the lab, all my boards are
reserved and scheduling for a multi-node job and thus, my lab is
basically dead.
Let me know if I can be of any help debugging this thing or testing a
possible fix. I'd have a look at the scheduler but you, obviously
knowing the code base way better than I do, might have a quick patch on
hand.
Best regards,
Quentin
Hi everyone,
I am writing this email in order to have your opinion on the following :
I am trying to use LAVA Notifications in my LAVA instance. I used the
following template in one of my LAVA Test Job Definition files :
notify:
recipients:
- to:
method: email
email: conrad.djedjebi(a)linaro.org
criteria:
status: complete
verbosity: verbose
compare:
query:
name: OPTEE_xtest_Jobs
username: admin
In that template, OPTEE_xtest_Jobs is the name of a query (testjob query)
and admin is the user who owns that query. The query is listing all the
completed jobs of that kind (I mean that the job I am currently running
will be listed in the query OPTEE_xtest_Jobs).
But each time my LAVA job is completed, I am not getting any email
notification.
In my user profil (my user name is conrad in the instance of LAVA I am
working on), I already provided an email. So even if I used the following
template, I should have get an email notification :
notify:
recipients:
- to:
method: email
user: conrad
criteria:
status: complete
verbosity: verbose
compare:
query:
name: OPTEE_xtest_Jobs
username: admin
Is there a point I missed? If anyone has some advices to give me in order
to get the notifications work, I would appreciate.
regards,
> lava-server and lava-dispatcher have been merged into a single source repository - lava
If you ask me, this is the (very) questionable decision. Indeed!?
lava-server is the front-end manager of the whole Lava test
environment, while lava-dispatcher is the back-end. Connected/splitted
by ZMQ protocol. And... They should be separately maintained, since
they represent (very) different things. Essentially, they do (very)
different tasks. They are, after all, apples and oranges.
In other words, if you update/buy advanced/more expensive apples, you
also force testers to update for nuthin'/buy for the loss the same
oranges, they had before?!
Is it the wise decision???
Two cents worth lamenting/analysis,
Zoran
_______
On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams <neil.williams(a)linaro.org> wrote:
> This is for particular note for developers as it changes the way that
> reviews happen.
>
> If you've noticed a few reviews being abandoned, this is why.
>
> lava-server and lava-dispatcher have been merged into a single source
> repository - lava
>
> lava-coordinator will follow in time, to ease the update of lava-coordinator
> to Python3.
>
> This will, in future, allow easier testing of device integrations by
> allowing the lava_scheduler_app unit tests to be linked to the
> lava_dispatcher unit tests and have a single review which adds both sides of
> the device support.
>
> There will be a lot of testing, as normal, so staging will be moving to
> packages built from the new source repository tree.
>
> The old lava-server.git and lava-dispatcher,git repositories will become
> read-only and will get no further code changes. All changes will be done in
> lava.git
>
> https://git.linaro.org/lava/lava.git/
>
> The documentation will be updated over the next few days.
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
>
> _______________________________________________
> Lava-announce mailing list
> Lava-announce(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-announce
>
Good morning everyone,
I am looking for few guidelines while using device tags in LAVA. The
following link on LAVA Documentation's webpage explains how to use tags:
https://staging.validation.linaro.org/static/docs/v2/developing-tests.html
*However, once the tags are created, how to assign them to specific devices
?*
I created tags in the scheduler app, but I am not finding any option in the
web page of LAVA to assign a specific tag to a specific device.
I saw many devices using tags in LAVA LAB. I hope the engineers who set up
those devices can give me advice. If anyone else has some ideas about the
trick around setting up those tags, I would appreciate.
regards,
I had a notification section as follows
notify:
criteria:
status: complete
verbosity: verbose
callback:
url: http://localhost:8080/scheduler/job/{ID}
method: POST
token: mytoken
content-type: json
dataset: results
recipients:
- to:
method: email
email: address(a)site.org
largely copying that from other examples as experiments. I've been
seeing as I changed other parts of the health check that it was failing
- timing out when booting the kernel. If I remove the callback section
so
notify:
criteria:
status: complete
verbosity: verbose
recipients:
- to:
method: email
email: address(a)site.org
then the health check consistently works. Is there some side effect
going on here - or is my callback section causing the error, that
localhost url should be ok. I'd expect it to always fail if there's a
problem with it?
Robert
Hi All,
I have Debian 9(stretch) installed on my system and I want to install LAVA
2018.2 (server as well as the dispatcher), I used "*deb
https://images.validation.linaro.org/production-repo
<https://images.validation.linaro.org/production-repo> stretch-backports
main*" repository for this.
But it only installing LAVA 2017.7 version and it's only showing
LAVA-server version 2018.2 in the upgrade but not LAVA-dispatcher-2018.2.
Please suggest do I need to use some different repository for
LAVA-dispatcher-2018.2?
Thanks,
Ankit
Hello All,
I am following
https://validation.linaro.org/static/docs/v2/results-intro.html for charts
and queries.
My LAVA version is
$ dpkg -l lava-server
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Version Architecture Description
+++-==============================================-============================-============================-==================================================================================================
ii lava-server
2018.2+7178.53c57de9-1+stret all Linaro Automated
Validation Architecture server
I have created "test job" query and added that query while running my job
by adding below lines in my job
notify:
recipients:
- to:
method: email
user: mayuri
criteria:
status: complete
verbosity: verbose
query:
name: test_job
username: mayuri
But,I am getting only email notifications of test result for this job but,
I am not getting any query related information or chart related information
through this job. Only one message related to query I am getting which is "
No query is set for results comparing"
Please help me in to this.
Regards,
Mayuri
Hi Conrad,
one of the devices in our setup is a nexus4, which will be most useful for
reference.
It has this device dictionary jinja:
{% extends 'nexus4.jinja2' %}
{% set adb_serial_number = 'someserialnumber' %}
{% set fastboot_serial_number = 'someserialnumber' %}
{% set device_info = [{'board_id': 'someserialnumber'}] %}
{% set static_info = [{'board_id': 'someserialnumber'}] %}
Maybe the fastboot_serial_number is the critical part here? I think some
parts in the device type definition expected this value to be defined.
The device type is the nexus4 definition that is included in LAVA. It runs
with the health check from the LAVA repos [1], expect that Debian Sid is
replaced by Stretch for LXC (seems that the scripts are not compatible with
the current Sid).
Adding the following test demonstrates some fastboot commands that work
here:
- test:
namespace: tlxc
timeout:
minutes: 5
definitions:
- from: inline
name: some-fastboot-commands
path: inline/some-fastboot-commands.yaml
repository:
metadata:
format: Lava-Test Test Definition 1.0
name: some-fastboot-commands
description: "some-fastboot-commands"
run:
steps:
- adb start-server || true
- adb wait-for-device
- adb reboot bootloader
- sleep 60
- fastboot devices -l
- fastboot reboot
- sleep 10
- adb wait-for-device
The LAVA master+dispatcher are running on Debian Buster. LAVA version is
2018.2-1 (Debian packages).
[1]
https://git.linaro.org/lava-team/refactoring.git/tree/health-checks/nexus4.…
Regards,
Karsten
On Wed, Apr 11, 2018 at 8:42 PM, Conrad Djedjebi <conrad.djedjebi(a)linaro.org
> wrote:
> Hi Karsten,
>
> Thank you for your answer,
>
> In the device dictionnary, I wrote the board_id number but neither
> vendor_id nor product_id. I did the same thing as you. My adb serial number
> is the same as my fastboot serial number. The board_id was set to
> adb/fastboot serial number.
>
> It is really strange that the device is not being discovered in fastboot
> mode.
>
> Can you share with me the configuration you used while testing fastboot? (Is
> it a debian LXC?, which versions of fastboot/adb packages did you use? If
> you runned a LAVA Test Job Definition, can you share it with me?). There
> must be a detail I missed.
>
> Thanks
>
> Regards,
>
> Le mer. 11 avr. 2018 à 19:58, Karsten Tausche <karsten(a)fairphone.com> a
> écrit :
>
>> Hi,
>>
>> out of curiosity I tried using fastboot on our setup. It works here
>> without any issues. Could your problem be related to different USB meta
>> data reported in adb and fastboot mode? The documentation here [1] suggests
>> to add usb_vendor_id/usb_product_id to the device dictionary. However,
>> these can be different in different boot stages. That's why I'm only
>> setting board_id, which is for our devices the Android serial number and
>> equal to iSerial reported by lsusb in fastboot and adb modes.
>>
>> Regards,
>> Karsten
>>
>> [1] https://staging.validation.linaro.org/static/docs/v2/
>> admin-lxc-deploy.html#android-testing-with-lxc-support
>>
>> On Wed, Apr 11, 2018 at 4:31 PM, Conrad Djedjebi <
>> conrad.djedjebi(a)linaro.org> wrote:
>>
>>> Hi Senthil, Chris,
>>>
>>> Thank you for your answers,
>>>
>>>
>>> Senthil, the udev rule is triggered each time my device switch from
>>> fastboot to adb mode or from adb to fastboot mode. I tried the process of
>>> switching from adb to fastboot mode and vice versa in the container. Before
>>> that, I uninstalled fastboot and adb packages from the host so there is no
>>> way the adb and fastboot daemons of the host are creating conflicts with
>>> the fastboot and adb deamons of the container.
>>>
>>>
>>> Each time the device enters adb mode, the udev rule is triggered and I
>>> can find the device with the command adb devices. But each time the device
>>> switchs to fastboot mode, I can 't see it with the command fastboot
>>> devices. I can see that the udev rule is triggered in the logs but the
>>> device is still not appearing. *I even did a "lxc-device -n myLxcName
>>> add /dev/bus/usb/001/056" manually to add the device to the container in
>>> fastboot mode*. The add process was done properly but there was still
>>> no fastboot device visible.
>>>
>>>
>>> Chris, my container is successfully adding the usb device each time it
>>> is plugged. In adb mode, I can easily run Android CTS or Android VTS test
>>> suites on the device. So I think the container have access to
>>> "/dev/bus/usb" and also to the host's network stack.
>>>
>>>
>>> Someone told me he had to add an additional mount entry
>>> into /usr/share/lxc/config/debian.common.conf otherwise fastboot could
>>> not see his device from the container. I will explore that option.
>>>
>>>
>>>
>>> *I am still looking for a way to fix my issue anyway.*
>>>
>>>
>>>
>>> regards,
>>>
>>>
>>> On 8 April 2018 at 14:47, Senthil Kumaran S <senthil.kumaran(a)linaro.org>
>>> wrote:
>>>
>>>> Hi Conrad,
>>>>
>>>> On Sunday 08 April 2018 06:39 PM, Conrad Djedjebi wrote:
>>>> > I am currently running jobs on a device through adb without issues.
>>>> LAVA
>>>> > is adding udev rules which make it possible for the LXC container to
>>>> > successfully attach the target.
>>>> >
>>>> > However, when the device turns into fastboot mode, a "fastboot
>>>> devices"
>>>> > command in the LXC returns nothing. In fastboot mode, the USB link of
>>>> > the device is added whereas the device is not listed among the
>>>> fastboot
>>>> > devices.
>>>>
>>>> The udev rules gets applied only when the device gets re-enumerated /
>>>> restarted ie., on an udev add event. Otherwise the udev rule will not
>>>> get applied to a device. For devices that are attached already when the
>>>> job starts or if the device will not get re-enumerated, then use
>>>> static_info as seen here -
>>>> https://git-us.linaro.org/lava/lava-lab.git/tree/
>>>> staging.validation.linaro.org/master-configs/staging-master.
>>>> lavalab/lava-server/dispatcher-config/devices/
>>>> staging-hi6220-hikey-r2-02.jinja2#n16
>>>> along with the device_info variable in the device dictionary.
>>>>
>>>> > In the host, a "fastboot devices" command returns the id of the
>>>> device.
>>>>
>>>> I haven't faced this. But on the other hand when the host runs adb
>>>> daemon, then it takes control of all the devices and the devices will
>>>> not be visible from within the containers (LXC), even when the udev rule
>>>> is applied. So care should be taken that 'adb' daemon is not running on
>>>> the host. It is good, not to run any operation with fastboot too on the
>>>> host, when the device is accessed via a container within the same host.
>>>>
>>>> Thank You.
>>>> --
>>>> Senthil Kumaran S
>>>> http://www.stylesen.org/
>>>> http://www.sasenthilkumaran.com/
>>>>
>>>
>>>
>>> _______________________________________________
>>> Lava-users mailing list
>>> Lava-users(a)lists.linaro.org
>>> https://lists.linaro.org/mailman/listinfo/lava-users
>>>
>>>
>>
Hello,
in order to validate that lava-server and lava-dispatcher are not
regressing from one version to another, we added a lot of unit tests that
are run every time a commit is pushed under review on
https://review.linaro.org/
Before each release, we also run integrations tests on real hardware.
However, we don't have access to most of the hardware currently supported
by LAVA. Which mean that we cannot fully tests that LAVA is not regressing.
For this reason, we created a project called meta-lava (currently available
at https://framagit.org/ivoire/meta-lava)
When run, meta-lava will:
1/ build a docker image for lava-server and lava-dispatcher
* install lava-server and lava-dispatcher Debian packages from the
production repo
* pull the sources from git and overwrite installed sources
2/ start the containers in a specific network (meta-lava-net)
3/ wait for lava-slave to connect to the master
4/ launch a bunch of tests
5/ compare the results against the expected results
In order to run the tests (as the meta-lava slave is *not* connected to any
real hardware), we use a program called DummySys (
https://framagit.org/ivoire/DummySys) that will:
* print the exact lines that lava is expecting
* expect the exact inputs that lava is supposed to send
This allow to test that lava will always behave exactly the same, for a
given type of board, from one release to another.
We can also simulate hardware failures, kernel crashes, ...and check that
LAVA will continue to report the error correctly.
meta-lava is currently running health-check for 24 device types (see
https://framagit.org/ivoire/meta-lava/tree/master/tests/health-checks) and
also checking for some common errors (like auto-login failures) or use
cases (doing a GET on a given url when a job is finished).
However without some help from the lava community we won't be able to add
every boards that you care about nor all your specific use cases.
So if you are interested, please raise your hand and contact me.
Thanks
--
Rémi Duraffort
LAVA Team
Linaro
