Hello,
What is the rationale to ignore individual lava-test-case results when running a health check jobs?
For example, the following job failed one case: https://validation.linaro.org/scheduler/job/1902316
A failing test case can be an indication of device malfunction (e.g. out of disk space, hw issues). Is it possible to force LAVA to fail a health check and thus put device in a "bad" state if one of the test cases is not successful?
Thanks,
Andrei Narkevitch
Cypress Semiconductors
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
After setup a master & a worker, I add this worker to this master, also add device to this worker.
Then submit this job, the web page just show the task is in the status "Submit".
The same configures seems work on my local machine(with master & worker on the same machine)
I cannot find the root cause as job's device-type which the device have is idle & the health is good.
For such kind of issue, any way to debug? I mean if any log I can find for why lava cannot dispatch the task with its 20 seconds poll?
Hello,
please keep the mailing-list in copy when replying.
thanks for your help . I will discuss two questions (1. Change site
> issue ; 2 secure boot mode ; ) in this reply.
> 1) Change site issue : We changed both 'display name' and
> 'display name' (example.com ) to IP address , and now we found that we
> couldn't login in , when we pressed login in link on home page , it
> reported as below:
>
>
> *500 Internal Server Error**Site matching query does not exist.*
>
> *Oops, something has gone wrong! *
>
That's really strange. Could you update /etc/lava-server/settings.conf to
set "DEBUG" to true, restart lava-server-gunicorn, refresh the page and
send back the stack trace.
Keep in mind that settings.conf is a json file, so check that the syntax is
valid json.
> 2) secure boot mode : at present , we solved it by utilizing
> ''ramdisk" key words and forcing it not to decompress utee file , but we
> don't know if we will utilize this key words in the future , so maybe it's
> not a good solution. If we find any better solution after we reviews all
> source codes ,we will submit it !
>
Right.
Rgds
--
Rémi Duraffort
Dear all,
I'm trying booting my devices under test in a secure boot mode , which means i have to download dtb、kernel 、uTee files and set nfs serverip to mount rootfs in uboot , so there's an extra uTee file . And i checked key words in deploy steps and there was none extra for this action . And we only found 'image' 、’ramdisk‘、'dtb'、'rootfs' in job_templates.py under lava_server directionary . So what should i do to add this action in deploy？
Dear all,
I'm bothered with lava site changing function( at http://10.193.101.30/admin/sites/site/1/change/ , pls change IP address here to yours). When i changed default domain name to IP address and set notification email in my job as below:
notify:
recipients:
- to:
method: email
email: temp(a)163.com
criteria:
status: complete
verbosity: verbose
and then i received messy code as below:
Job details and log file: http://???/scheduler/job/19
So I just don't know what's wrong!
Hi lava team,
I want to use lava for running shell scripts on several devices which are connected to the lava server via ssh.
Is there a way to deploy the overlay to another directory than "/"?
Example:
The overlay is downloaded to /lava-123.tar.gz and extracted to /lava-123 by default.
What if my rootfs "/" is read-only and I want to download and extract the overlay to /tmp or /data, which are read-write mounted?
Best regards,
Christoph
Hi all,
At NXP, we would like the result app to report regressions/progressions
between 2 tests.
We run CTS/VTS job on Android 9, and as we add some features to the OS (DRM
for example), we want to make sure we get the expected behavior. For that,
we need to know exactly which test cases results are different between the
two last jobs. CTS runs about 400 000-500 000 test cases, it's kind of
heavy to process manually.
For example, the result table could show 2 tables, one would be the same it
is atm, and the other would show the list of test cases results that are
different from the previous job.
What do you think about this ? I think this could be useful to everyone.
Should I submit an issue to https://git.lavasoftware.org/lava/lava/ ?
Best regards,
Axel
Im deploying lava using the docker container and I am looking at the
correct paths to mount as volumes as to not lose data between cluster
rollovers. (and to have to backups)
If I change the instance.conf to point to a database that is outside
of the container that gets backed up and includes these paths in my
volume mounts is that all I need to do? Or is there additional
paths/files that should be included.
https://master.lavasoftware.org/static/docs/v2/admin-backups.html
If anyone knows anything about this thanks!
Hi all,
I am running LTP tests through LAVA on a Yocto based system.
If I run a LTP test suite (like syscalls) by directly calling runltp, LAVA will display it as a single TC, with a single PASS/FAIL verdict.
I think the test definition here solves this problem: https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp…
But couldn't find a job template that makes use of it.
Could you please let me know:
* If this could run on yocto?
* Where to find an example job that makes use of this?
Thanks and regards,
Philippe
Hi, I have a problem for Installing LAVA server and dispatcher using
docker images that Linaro offer.
I installed both two images(server and dispatcher) on my local pc.
When I submit job, submitted job is listed on Lava server.
But it remain the status as 'Submitted' and not change.
When i visit server {local ip address:port number}/scheduler/device/qemu01,
I can see message like below.
Is this mean that health-check job have to be registered before
submitting test job? If then, how to do?
I have looked for the way to figure out this problem, but I couldn't.
Although I tried to disable health check on this device and forced to
change Health as 'Good',
Health status soon change like Good → Bad (Invalid device configuration).
Below is what I did for installing LAVA server and dispatcher.
- LAVA Server
1) Pull docker image and run.
$ |docker pull lavasoftware/lava-server||:2018.11|
||$ docker run -itd --name new_lava_server --cap-add=NET_ADMIN \||
|| -p 9099:80 -p 5557:5555 -p 5558:5556 -h new_lava_server \
||
|| lavasoftware/lava-server||||:2018.11||
||2) Create superuser||
||Create id as admin, pw as admin.||
||||
||$ ||||lava-server manage createsuperuser||
||3) Create token||
||Create token for admin account on server web ui.||
4) Add device type and device
$ lava-server manage device-types add qemu
5) Add device dictionary
$ lava-server manage devices add --device-type qemu --worker
new_lava_slave qemu01
- LAVA dispatcher
1) Pull docker image and run.
$ |docker pull lavasoftware/lava-dispatcher||:2018.11|
|$ ||docker run -it --name new_lava_slave \|
|||-||v||/boot||:||/boot||-||v||/lib/modules||:||/lib/modules||-||v||/home/lava-slave/LAVA-TEST||:||/opt/share||\|
|||-||v||/dev/bus/usb||:||/dev/bus/usb||-||v||~/.||ssh||/id_rsa_lava||.pub:||/home/lava/||.||ssh||/authorized_keys||:ro
-||v||/sys/fs/cgroup||:||/sys/fs/cgroup||\|
|||--device=||/dev/ttyUSB0||\|
|||-p 2022:22 -p 5555:5555 -p 5556:5556 \|
|||-h new_lava_slave \|
|||--privileged \|
|||-e LAVA_SERVER_IP=||"192.168.1.44"||\|
|||-e||"LOGGER_URL=tcp://192.168.1.44:5557"||\|
|||-e||"MASTER_URL=tcp://192.168.1.44:5558"||\|
|||-e||"DISPATCHER_HOSTNAME=--hostname=new_lava_slave"||\|
|||lavasoftware||/lava-dispatcher||:2018.11|
|2) Submit job file|
||
$ ./submityaml.py -p -k apikey.txt qemu01.yaml
|Below is submityaml.py python code.|
|apikey.txt file is token created on server.
|
||
#!/usr/bin/python
import argparse
import os.path
import sys
import time
import xmlrpclib
SLEEP = 5
__version__ = 0.5
LAVA_SERVER_IP = "192.168.1.44"
def is_valid_file(parser, arg, flag):
if not os.path.exists(arg):
parser.error("The file %s does not exist!" % arg)
else:
return open(arg, flag) # return an open file handle
def setup_args_parser():
"""Setup the argument parsing.
:return The parsed arguments.
"""
description = "Submit job file"
parser = argparse.ArgumentParser(version=__version__,
description=description)
parser.add_argument("yamlfile", help="specify target job file",
metavar="FILE",
type=lambda x: is_valid_file(parser, x, 'r'))
parser.add_argument("-d", "--debug", action="store_true",
help="Display verbose debug details")
parser.add_argument("-p", "--poll", action="store_true", help="poll
job status until job completes")
parser.add_argument("-k", "--apikey", default="apikey.txt",
help="File containing the LAVA api key")
parser.add_argument("--port", default="9099", help="LAVA/Apache
default port number")
return parser.parse_args()
def loadConfiguration():
global args
args = setup_args_parser()
def loadJob(server_str):
"""loadJob - read the JSON job file and fix it up for future submission
"""
return args.yamlfile.read()
def submitJob(yamlfile, server):
"""submitJob - XMLRPC call to submit a JSON file
returns jobid of the submitted job
"""
# When making the call to submit_job, you have to send a string
jobid = server.scheduler.submit_job(yamlfile)
return jobid
def monitorJob(jobid, server, server_str):
"""monitorJob - added to poll for a job to complete
"""
if args.poll:
sys.stdout.write("Job polling enabled\n")
# wcount = number of times we loop while the job is running
wcount = 0
# count = number of times we loop waiting for the job to start
count = 0
f = open("job_status.txt", "w+")
while True:
status = server.scheduler.job_status(jobid)
if status['job_status'] == 'Complete':
f.write("Complete\n")
break
elif status['job_status'] == 'Canceled':
f.write("Canceled\n")
print '\nJob Canceled'
exit(0)
elif status['job_status'] == 'Submitted':
sys.stdout.write("Job waiting to run for % 2d
seconds\n" % (wcount * SLEEP))
sys.stdout.flush()
wcount += 1
elif status['job_status'] == 'Running':
sys.stdout.write("Job Running for % 2d seconds\n" %
(count * SLEEP))
sys.stdout.flush()
count += 1
else:
f.write("unkonwn status\n")
print "unknown status"
exit(0)
time.sleep(SLEEP)
print '\n\nJob Completed: ' + str(count * SLEEP) + ' s (' +
str(wcount * SLEEP) + ' s in queue)'
def process():
print "Submitting test job to LAVA server"
loadConfiguration()
user = "admin"
with open(args.apikey) as f:
line = f.readline()
apikey = line.rstrip('\n')
server_str = 'http://' + LAVA_SERVER_IP + ":" + args.port
xmlrpc_str = 'http://' + user + ":" + apikey + "@" + LAVA_SERVER_IP
+ ":" + args.port + '/RPC2/'
print server_str
print xmlrpc_str
server = xmlrpclib.ServerProxy(xmlrpc_str)
server.system.listMethods()
yamlfile = loadJob(server_str)
jobid = submitJob(yamlfile, server)
monitorJob(jobid, server, server_str)
if __name__ == '__main__':
process()
|The job file named qemu01.yaml is below.|
||
|# Your first LAVA JOB definition for an x86_64 QEMU
device_type: qemu
job_name: QEMU pipeline, first job
timeouts:
job:
minutes: 15
action:
minutes: 5
connection:
minutes: 2
priority: medium
visibility: public
# context allows specific values to be overridden or included
context:
# tell the qemu template which architecture is being tested
# the template uses that to ensure that qemu-system-x86_64 is executed.
arch: amd64
metadata:
# please change these fields when modifying this job for your own tests.
docs-source: first-job
docs-filename: qemu-pipeline-first-job.yaml
# ACTION_BLOCK
actions:
- deploy:
timeout:
minutes: 5
to: tmpfs
images:
rootfs:
image_arg: -drive format=raw,file={rootfs}
url:
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
compression: gz
# BOOT_BLOCK
- boot:
timeout:
minutes: 2
method: qemu
media: tmpfs
prompts: ["root@debian:"]
auto_login:
login_prompt: "login:"
username: root
- test:
timeout:
minutes: 5
definitions:
- repository: http://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/smoke-tests-basic.yaml
name: smoke-tests|
|
|
||
