Hi,
I upgraded to LAVA 2017.7 (for now I'm using https://github.com/kernelci/lava-docker) and
managed to add my device-type and device as follows:
# Note: I didn't know how to update to 2017.9
docker# lava-server manage device-types add renesas-iwg20m
docker# lava-server manage devices add --device-type renesas-iwg20m --worker lava-docker iwg20m01
However, when I want to add the device dictionary I get an error.
# Note: I am following https://validation.linaro.org/static/docs/v2/pipeline-admin.html
First, I tried with "lava-server manage device-dictionary" as in the documentation, but I failed:
docker# lava-server manage device-dictionary
Unknown command: 'device-dictionary'
Is this only available in the 2017.9 version?
Then, I tried with " lava-tool device-dictionary localhost lava-docker --update myiwg20m.jinja2" but I
get:
Updating device dictionary for lava-docker on localhost
ERROR: Endpoint URL not found in the authorization list: localhost
[Note] my lava-tool is version 0.23-1 (the newest according to apt)
Now, there is a section saying "Using the command line
The device dictionary exists as a jinja2 file in /etc/lava-server/dispatcher-config/devices and can be updated by admins with the necessary access.".
Is this equivalent to using lava-server o lava-tool to install a device dictionary??
Others:
- I confirmed that Pipeline device? is checked.
- Django administration > Devices: what is the meaning of Hostname? I have a value of iwg20m01 (the name of the device),
there is no relation with the server/container's hostname, is there?
- There is an authentication token for the user 'kernel-ci'
Thanks,
Daniel
Hello,
My question looks pretty silly, but as Lava has a big set of features that I haven't discovered yet, I dare ask.
Lava is designed for automatic testing. But everything cannot be fully automated, at least in a reasonable development time frame. More precisely, tests execution can be automated, but the test result needs to be given by a tester. This will happen for example in display or graphics tests.
So, is there a simple way in Lava to let a tester give a manual test result, during or after the test execution? I already have in mind pretty complicated solutions based on Multinode, but simple is key here
Thanks,
Denis
Hi everyone,
As many of you may know, LAVA V2 has been in development and is now ready to roll out across all instances, and we have started this transition with most micro-instances now being predominantly V2.
That leaves the main production instance, validation.linaro.org. Of the supported device types in V2 16 of the 21 have been fully switched over already. Most of these devices can accept V1 and V2 job submissions, but for underlying structural reasons some device types can *only* be V1 or V2, not both.
This is to let you know that in the week following SFO17 we will be switching those devices (HiKey, Drangboard 410c, X15, IFC6410 and Mustang) to V2 only, and any job submissions that are in the old JSON format will be rejected by the LAVA scheduler. If you have bots that submit V1 jobs to those device types, or if you manually submit V1 jobs to those device types, you are strongly urged to switch those off and move to V2 submissions.
The next release of LAVA software will not support V1 at all, so for anyone submitting V1 jobs to *any* device, you will need to move to V2 by the beginning of November at the latest.
Many thanks
Dave
----------------
Dave Pigott
LAVA Lab Lead
Linaro Ltd
t: (+44) (0) 1223 400063
Hello Lava team,
I am trying to test a flashed board that does'nt require to upload tests images ( uImage dtb, rootfs).
The images have been previously flashed on the board under test, by an external Flasher.
To do that, I am using the boot method "minimal" that we have been using for other cases.
In my test, I power on the board, and wait for the kernel prompt ("root@").
When I got the prompt, LAVA try to mount the test partition (previously prepared in deploy phase),
but it fails. I get the following message "No connection retrieved from namespace data".
* Is it possible to do this operation with the boot method "minimal" ?
* Do you have jobs example that do the same operations ?
Find below the boot and test phase I am using :
( In the deploy phase, I have downloaded images that I don't use. )
- boot:
method: minimal
failure_retry: 2
prompts:
- 'root@'
timeout:
minutes: 2
- test:
timeout:
minutes: 5
namespace: flash_to_sd
definitions:
- from: git
repository: /local/dev/frq93151/dispatcher/lava-tests
path: tests-def/ddr_test_definition.yaml
name: ddr_tests
BR
Philippe
Hi all,
I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now I can't sign in with the local Django user, this is the error infomations:
Forbidden (403)
CSRF verification failed. Request aborted.
You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties.
If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests.
More information is available with DEBUG=True.
Please give me some advices!
root@hxtcorp:~# dpkg-query -l lava*
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-coordinator 0.1.7-1 all LAVA Coordinator daemon
un lava-dashboard <none> <none> (no description available)
un lava-dashboard-tool <none> <none> (no description available)
ii lava-dispatcher 2017.7-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher
un lava-scheduler <none> <none> (no description available)
un lava-scheduler-tool <none> <none> (no description available)
ii lava-server 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture server
ii lava-server-doc 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture documentation
ii lava-tool 0.21-1 all command line utility for LAVA
un lavapdu <none> <none> (no description available)
ii lavapdu-client 0.0.5-1 all LAVA PDU client
ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon
add the local Django user:
sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL
sudo lava-server manage authorize_superuser --username $USERNAME
root@hxtcorp:/etc/lava-server# lava-server manage users list
List of users:
* 1680077
* 1680141
* lava-health
* xuhy
Best Regards
XuHongyu
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
Hi all,
I used LAVA V1 before and I want to migrate to LAVA V2 following the guide " First steps installing LAVA V2" .
I had a problem when adding pipeline workers to the master. After input the command " sudo lava-server manage workers add <HOSTNAME>", I got error "Unknown command: 'workers'" and I failed to find help by typing "lava-server -h manage".
Can anybody help me on this step?
BTW, I want to know whether multiple workers can have the same hostname ?
Thanks in advance.
Hi,
The tests in https://git.linaro.org/qa/test-definitions.git in some
cases have license in the subdirectories but there's no top level
licence file covering the whole repository. Would you like a PR
submitting to cover this or do you envisage the maintainers making this
change themselves? We're hoping to use some of these and so wanted
licences to be consistent. We'd also be prepared to review licences
in future repository changes.
The licenses that I've found all seem to be GPL v2 so I assume that is
the license flavour which should be covering the whole repos.
Robert
Hi Lava users,
I just updated lava from 2016.12 to 2017.6-1. And I found my health-check
job failed(uncomplete) after the update.
Here is the result logs before:
https://pastebin.com/KWAnYQvD
and after:
https://pastebin.com/mqXDfR3H
I checked the log and think the cause for the issue is:
```
case: job
definition: lava
error_msg: constants section not present in the device config.
error_type: Configuration
result: fail
```
What I have done:
* Try to find the "constants section" with no luck.
* Looked at the logs in /var/lava-server/ and didn't find the log specific
for the reason of this.
* Asked IRC channel and ask, answered by codehelp(thanks:)). Then tried to
replace my device-type config
in /etc/lava-server/dispatcher-config/device-types with x86.jinja2 and the
error message is the same.
Any input would by much appreciated, thank you.
Regards,
-Michael Chen
Hi Lava Team,
I am using Lava image on debian stretch from https://images.validation.linaro.org/production-repo stretch-backports main & in It chart/query api is working.
Then I took latest code from lava release branch https://github.com/Linaro/lava-server/commits/release to my local branch
Tag taken :- c0b431f1b56227f6b97ba0e7859bfcc3fb29b62f refs/tags/2017.7
& build it but Lava charts is not coming when I run lava server["python manage.py runserver"] using latest code from git??
Can you please share where is latest code being used in debian stretch located?
Thanks,
Varun
