- lava-users - op-lists.linaro.org

by Chuan Su

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!

7 years, 3 months

2
1
0 0

change overlay deploy destination via ssh

by Krutz, Christoph

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

7 years, 3 months

1
0
0 0

Result app report test case regressions

by Axel Lebourhis

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

7 years, 3 months

3
7
0 0

Docker recommended volume mounts?

by Chris Sauer

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!

7 years, 3 months

4
11
0 0

Best way to run LTP tests on yocto

by Philippe Mazet

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

7 years, 3 months

3
4
0 0

Have health-check job to be registered before submitting test job?

by tomato

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| | | ||

7 years, 3 months

2
1
0 0

FW: Timeouts in LAVA failing

by Patryk Mungai Ndungu

Hello, I have noticed sometimes when I run healthchecks, LAVA gets stuck when doing a http download of the kernel and ramdisk to run a healthcheck. For example in [1] there seems to be a 3 min timeout for the deploy images section, but LAVA didn’t pick this up, and was stuck there for 17 hours. After the job was cancelled and the device health was manually set to unknown again, the healthcheck succeeds (eg. job 25 on the same lava instance). I am running LAVA 2018.7. [1] https://lava.ciplatform.org/scheduler/job/20 Thanks, Patryk Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

7 years, 3 months

2
1
0 0

Dependencies between master and worker when restoring from backups

by Tim Jaacks

Hello everyone, I have written a backup script for my LAVA instance. While testing the restore process I stumbled upon issues. Are there any dependencies between the master and workers concerning backups? When the master crashes, but the worker does not, is it safe to restore the master only and keep the worker as it is? Or do I have to keep master and worker backups in sync and always restore both at the same time? Restoring my master as described in the LAVA docs generally works. The web interface is back online, all the jobs and devices are in consistent states. Restoring the worker is relatively easy, according to the docs. I installed the LAVA packages in their previous versions on a fresh (virtual) machine, restored /etc/lava-dispatcher/lava-slave and /etc/lava-coordinator/lava-coordinator.conf. The worker has status "online" in the LAVA web interface afterwards, so the communication seems to work. However, starting a multinode job does not work. The job log says: lava-dispatcher, installed at version: 2018.5.post1-2~bpo9+1 start: 0 validate Start time: 2018-12-18 12:25:14.335215+00:00 (UTC) This MultiNode test job contains top level actions, in order, of: deploy, boot, test, finalize lxc, installed at version: 1:2.0.7-2+deb9u2 validate duration: 0.01 case: validate case_id: 112 definition: lava result: pass Initialising group b6eb846d-689f-40c5-b193-8afce41883ee Connecting to LAVA Coordinator on lava-server-vm:3079 timeout=90 seconds. This comes out in a loop, until the job times out. The lava-slave logfile says: 2018-12-18 12:27:15,114 INFO master => START(12) 2018-12-18 12:27:15,117 INFO [12] Starting job [...] 2018-12-18 12:27:15,124 DEBUG [12] dispatch: 2018-12-18 12:27:15,124 DEBUG [12] env : {'overrides': {'LC_ALL': 'C.UTF-8', 'LANG': 'C', 'PATH': '/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/sbin:/sbin'}, 'purge': True} 2018-12-18 12:27:15,124 DEBUG [12] env-dut : 2018-12-18 12:27:15,129 ERROR [EXIT] 'NoneType' object has no attribute 'send_start_ok' 2018-12-18 12:27:15,129 ERROR 'NoneType' object has no attribute 'send_start_ok' It is the "job = jobs.create()" call in lava-slave's handle_start() routine which fails. Obviously there is a separate database on the worker (of which I did not know until now), which fails to be filled with values. Does this database have to be backup'ed and restored? What is the purpose of this database? Is there anything I need to know about it concerning backups? 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

7 years, 3 months

2
5
0 0

Re: [Lava-users] Lava job always exits when running a long duration test case without outputs

by Neil Williams

Please make sure you include the mailing list in all replies so that others know when a problem has been fixed (and how it was fixed) On Tue, 18 Dec 2018 at 12:00, Chuan Su <lavanxp(a)126.com> wrote: > > According to your comments , we checked our setups and we found that we utilized ser2net & telnet to communicate with DUT , however , ser2net set default timeout parameter as 600 seconds . When DUT runs a long duration case (more than 600 seconds ) without any log outputting , the connection is usually dropped by ser2net , and telnet program always prints logs as 'Connection closed by foreign host ' . Anyway thanks for your help ! See https://git.linaro.org/lava/lava-lab.git/tree/shared/server-configs/ser2net… The Linaro lab in Cambridge sets all the ser2net configs to have a zero timeout. > Sincerely, > Chuan Su > > > > > > At 2018-12-18 15:59:00, "Neil Williams" <neil.williams(a)linaro.org> wrote: > >On Tue, 18 Dec 2018 at 06:16, Chuan Su <lavanxp(a)126.com> wrote: > >> > >> Dear all, > >> We are encountered with an issue that our job always exits halfway when running a long duration test case (around 20 minutes) which outputs nothing , and lava server reports an InfrastructureError error and prints as below : > >> Connection closed by foreign host.Marking unfinished test run as failed > > > >Connection closed by foreign host means that the serial connection > >failed at the DUT - this is not a problem in the LAVA test job, this > >is an infrastructure failure at your end. The foreign host (the DUT) > >closed the serial connection. There is nothing LAVA can do about that. > >The serial connection to the DUT has simply failed. > > > >If the serial connection is USB, check for logs on the worker like > >/var/log/messages and /var/log/syslog for events related to the serial > >connection. Check that the DUT didn't simply kill the serial > >connection - maybe the DUT went into some kind of suspend mode. > > > >> definition: lava > >> result: fail > >> case: 0_apache-servers1 > >> uuid: 597_1.4.2.4.1 > >> duration: 603.53 > >> lava_test_shell connection dropped.end: 3.1 lava-test-shell (duration 00:10:05) [ns_s1] > >> namespace: ns_s1 > >> extra: ... > >> definition: lava > >> level: 3.1 > >> result: fail > >> case: lava-test-shell > >> duration: 604.55 > >> lava-test-retry failed: 1 of 1 attempts. 'lava_test_shell connection dropped.'lava_test_shell connection dropped. > >> > >> And we just test it with a very simple python script as below: > >> #!/usr/bin/env python3 > >> import time > >> print('Hello,world!') > >> time.sleep(1200) > >> print("Hello,Lava!") > >> We can see 'Hello,world!' string outputs , but there's no more output of this program found on webUI! > >> We just don't know what's wrong , so we have to mail to you for help! > >> Sincerely, > >> Chuan Su > >> > >> > >> > >> > >> _______________________________________________ > >> Lava-users mailing list > >> Lava-users(a)lists.lavasoftware.org > >> https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > > > > >-- > > > >Neil Williams > >============= > >neil.williams(a)linaro.org > >http://www.linux.codehelp.co.uk/ > > > > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 3 months

1
0
0 0

Default patterns and fixup dicts in Lava-Test Test Definition 1.0

by Neil Williams

https://git.lavasoftware.org/lava/lava/issues/179 If your Lava-Test Test Definition 1.0 YAML files explicitly use a parse: block (like: https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp…) then this will remain supported in Definition 1.0. If you use the monitors or interactive test actions, this does not affect you at all. If you rely on LAVA to create a TestCase based on a command in the Lava-Test Test Definition just echoing "pass" or "fail", then this is the Default Pattern and this change will directly affect those test jobs. The current Default Pattern and Fixup are lifted directly from V1 (https://git.lavasoftware.org/lava/lava/blob/master/lava_common/constants.py…): # V1 compatibility DEFAULT_V1_PATTERN = "(?P<test_case_id>.*-*)\\s+:\\s+(?P<result>(PASS|pass|FAIL|fail|SKIP|skip|UNKNOWN|unknown))" DEFAULT_V1_FIXUP = { "PASS": "pass", "FAIL": "fail", "SKIP": "skip", "UNKNOWN": "unknown", } We've recently updated the documentation to drop mention of the default pattern support for the following reasons: * It has always been problematic to encode a Python regular expression in YAML. Failures are difficult to debug and patterns are global for the entire test operation. * The move towards more portable test definitions puts the emphasis on parsing the test output locally on the DUT using a customised parser. This has further advantages: * The pattern does not have to be mangled into YAML * The pattern can be implemented by a language other than Python * The pattern can change during the operation of the test shell, e.g. a different pattern may be required for setup than for the test itself. We are now starting to plan for Lava-Test Test Definition 2.0 with an emphasis on requiring portable test scripts and removing more of the lava_test_shell Test Helper scripts. Full information on 2.0 will be available early in 2019. As a first step, the generally unhelpful Default Pattern and Default Fixup dict are likely to be removed. If you need this support, the pattern can be added to your Lava-Test Test Definition 1.0 YAML files. In the next release, it is proposed that unless an explicit pattern is specified in the Lava-Test Test Definition 1.0 YAML file, then no pattern will be implemented. Processes which echo "pass" or "fail" would be ignored and no TestCase would be created. Let us know if there are any thoughts or problems on this proposal. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 3 months

1
0
0 0

Lava job always exits when running a long duration test case without outputs

by Chuan Su

Dear all, We are encountered with an issue that our job always exits halfway when running a long duration test case (around 20 minutes) which outputs nothing , and lava server reports an InfrastructureError error and prints as below : Connection closed by foreign host.Marking unfinished test run as failed definition: lava result: fail case: 0_apache-servers1 uuid: 597_1.4.2.4.1 duration: 603.53 lava_test_shell connection dropped.end: 3.1 lava-test-shell (duration 00:10:05) [ns_s1] namespace: ns_s1 extra: ... definition: lava level: 3.1 result: fail case: lava-test-shell duration: 604.55 lava-test-retry failed: 1 of 1 attempts. 'lava_test_shell connection dropped.'lava_test_shell connection dropped. And we just test it with a very simple python script as below: #!/usr/bin/env python3 import time print('Hello,world!') time.sleep(1200) print("Hello,Lava!") We can see 'Hello,world!' string outputs , but there's no more output of this program found on webUI! We just don't know what's wrong , so we have to mail to you for help! Sincerely, Chuan Su

7 years, 3 months

2
1
0 0

Git authentication

by Axel Lebourhis

Hi everyone, Is it possible to handle git authentication in a test job ? I need LAVA to clone a repo that can't be set to public, and obviously it won't work because of the authentication step. So is it possible to specify a password or a token ? Best regards, Axel

7 years, 4 months

5
12
0 0

LAVA webUI hangs when test case outputs long string in a line

by Chuan Su

Dear , all We found that when lava executed a script which may output a long string (more than 30000 bytes) in a line (only one line break), lava web UI always hung and there was no more lava log outputting and devices under test (short for DUT) were still powered until Lava Job time-out function triggered , however, after checked the whole log file we found that cases behind the hanging case were executed (there's new files generated) . So the problem is that when lava encountered those cases lava web UI always hangs and DUTs may not be powered off when all the cases are completed ! best wishes, Chuan Su

7 years, 4 months

2
2
0 0

LAVA webUI hangs when test case outputs long string in a line

by Chuan Su

Dear , all We found that when lava executed a script which may output a long string (more than 30000 bytes) in a line (only one line break), lava web UI always hung and there was no more lava log outputting and devices under test (short for DUT) were still powered until Lava Job time-out function triggered , however, after checked the whole log file we found that cases behind the hanging case were executed (there's new files generated) . So the problem is that when lava encountered those cases lava web UI always hangs and DUTs may not be powered off when all the cases are completed ! best wishes, Chuan Su

7 years, 4 months

1
0
0 0

Re: [Lava-users] Steps for restoring a backup

by Tim Jaacks

On Mon, 11 Dec 2018 at 11:30, Neil Williams <neil.williams at linaro.org> wrote: > On Tue, 11 Dec 2018 at 11:28, Tim Jaacks <tim.jaacks(a)garz-fricke.com> wrote: > > > > Thanks, the CLI operations are very helpful for automating the process. > > However, the docs say that all devices in "Reserved" state have to > > have their "current job" cleared. I can use "lava-server manage devices details" > > to check whether this field is actually set. There is no command to > > modify it, though. Seems like using the Python API is the only way to > > go here, right? The same applies to setting "Running" jobs to "Cancelled". > > https://git.lavasoftware.org/lava/lava/merge_requests/273 > > This should get into the upcoming 2018.12 release. Thank you very much for your quick help. The "lava-server manage jobs fail" command takes care of clearing the "current job" field of the associated device, do I understand that right? 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

7 years, 4 months

2
4
0 0

MultiNode Tradefed-runner with session retry

by Karsten Tausche

Hi folks, We at Fairphone have developed a variant of the Tradefed-runner in LAVA test-definitions that is meant to run complete Tradefed test suites on multiple devices by making use of the shards feature in Tradefed. The runner is currently in “staging” state. We still want to share now what we are using and developing to see if there are more people with interest in it. Feedback on the general approach taken would also be much appreciated. On the higher level, our setup works as follows: • Use MultiNode to allocate multiple devices for one test submission. • One “master” runs the Tradefed shell, similarly as in the existing runner. • The master connects to the workers’ DUTs via adb TCP/IP. These DUTs are transparently available to Tradefed just in the same way as USB-attached devices. • Workers ensure that their respective DUTs remain accessible to the master, especially in case of WLAN disconnects, reboots, crashes, etc. Major features of our runner: • Support for Android CTS, GTS and STS. • Test run split into “shards” in Tradefed to run tests in parallel on multiple devices. This allows for a major speedup when running large test suites. • Tradefed retry: Rerun test suites until the failure count stabilizes. • No adb root required. • Based on the original Tradefed runner, having at least parts of the common code moved to python libraries. Current limitations: • Test executions are not always stable. This needs further investigation. • Test executions produce more false positives than local test runs. This needs further investigation but is at least partially due to using adb TCP/IP instead of a local USB connection. • Android VTS not implemented (would require only minor changes) Our current changes have been pushed to the tradefed_shards_with_retry topic on Gerrit[1]. Besides the two major changes to add MultiNode adb support and then Tradefed support on top of that, a couple of smaller changes that could be useful on their own have also been pushed. We are looking forward to your feedback and to joint efforts in automating and speeding up Tradefed test executions! Best regards, Karsten for the Fairphone Software Team [1] https://review.linaro.org/q/topic:%22tradefed_shards_with_retry%22+(status:…

7 years, 4 months

2
1
0 0

Re: [Lava-users] Steps for restoring a backup

by Tim Jaacks

On Mon, 10 Dec 2018 at 20:16, Neil Williams <neil.williams at linaro.org> wrote: > Yes, there is a problem there - thanks for catching it. I think the > bulk of the page dates from the last stages of the migration when V1 > data was still around. I'll look at an update of the page tomorrow. > Step 7 is a sanity check that the install of the empty instance has > gone well, Step 9 is to ensure that the newly restored database is put > into maintenance as soon as possible to prevent any queued test jobs > from attempting to start. The critical element of Step 9 is to ensure > that the lava-master service is stopped. > > The emphasis of the section is on ensuring that the instance only > serves a "Maintenance" page, e.g. the default Debian "It works!" > apache page, to prevent access to the instance during the restore. Thanks for pointing that out, Neil. I got the point, that the Apache server has to serve a static site during the restore process. > Accessing the UI would involve having an alternative way to serve the > pages. If that can be arranged, just for admins, (e.g. by changing the > external routing to the box or redirecting DNS temporarily) then the > UI on the instance can be used with the change that the > lava-server-gunicorn service does not need to be stopped (because > access has been redirected). Other services would be stopped. However, > this would involve a fair number of apache config changes, so is best > left to those admins who have such config already on hand. > > The operations can be done from the command line and that's probably > best for these docs. > > Step 7 can be replaced by: > > lava-server manage check --deploy > > Step 9 can be replaced by looping over: > > lava-server manage devices update --health MAINTENANCE --hostname ${HOSTNAME} > > or, if there are a lot of devices: > > lava-server manage maintenance --force > > (This maintenance helper has been fixed in master - soon to be 2018.12 > - so older versions would use the first command & loop.) Thanks, the CLI operations are very helpful for automating the process. However, the docs say that all devices in "Reserved" state have to have their "current job" cleared. I can use "lava-server manage devices details" to check whether this field is actually set. There is no command to modify it, though. Seems like using the Python API is the only way to go here, right? The same applies to setting "Running" jobs to "Cancelled". > I'll look at changing the page to use CLI operations for steps 7 and > 9. Some labs can do the http redirect / routing method but the detail > of that is probably not in scope for this page in the LAVA docs. I'll > add a note that admins have that choice but leave it for those admins > to implement. 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

7 years, 4 months

2
1
0 0

Steps for restoring a backup

by Tim Jaacks

Hello everyone, I am trying to implement a backup and restore routine for our LAVA server, based on the documentation: https://validation.linaro.org/static/docs/v2/admin-backups.html#restoring-a… The creation of the backup is straight-forward. I have problems with the order of the proposed restore steps, though. Step 6 is "Stop all LAVA services". However, afterwards in step 7 it says "Make sure that this instance actually works by browsing a few (empty) instance pages." This should obviously be done before, right? The actual problem is that step 9 says "In the Django administration interface, take all devices which are not Retired into Offline". This cannot be an ordering issue, because the LAVA services actually must not be available during these modifications. How do I use the Django admin interface, while all LAVA services are stopped? 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

7 years, 4 months

2
1
0 0

How to switch device-type base jinja with only one device?

by Larry Shen

Dear all, I have a question when use lava. Background: 1. I have only one hardware device with android. 2. I have a device-type jinja2 file start with "{% extends 'base-fastboot.jinja2' %}" Here, I use "adb reboot bootloader" to enter in to fastboot. 3. I have another device-type jinja2 file start with "{% extends 'base-uboot.jinja2' %}" Here, I use "fastboot 0" in uboot to enter in to fastboot. Now, we have a scenario which need to test with above both methods, but we just have one device, if possible user can define some parameter in job.yaml, then can switch between the two methods just for one device? Any suggestion? Thanks, Larry

7 years, 4 months

2
4
0 0

lava-logs crash in 2018.11

by Corentin Labbe

Hello I got the following crash with 2018.11 on debian stretch dpkg -l|grep lava ii lava 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture metapackage ii lava-common 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture common ii lava-coordinator 0.1.7-1 all LAVA Coordinator daemon ii lava-dev 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture developer support ii lava-dispatcher 2018.11-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher ii lava-server 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture server ii lava-server-doc 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture documentation ii lavacli 0.9.3-1~bpo9+1 all LAVA XML-RPC command line interface ii lavapdu-client 0.0.5-1 all LAVA PDU client ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon 2018-12-04 14:14:40,187 ERROR [EXIT] Unknown exception raised, leaving! 2018-12-04 14:14:40,187 ERROR string index out of range Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 193, in handle self.main_loop() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 253, in main_loop while self.wait_for_messages(False): File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 287, in wait_for_messages self.logging_socket() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 433, in logging_socket job.save() File "/usr/lib/python3/dist-packages/django_restricted_resource/models.py", line 71, in save return super(RestrictedResource, self).save(*args, **kwargs) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 796, in save force_update=force_update, update_fields=update_fields) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 820, in save_base update_fields=update_fields) File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", line 191, in send response = receiver(signal=self, sender=sender, **named) File "/usr/lib/python3/dist-packages/lava_scheduler_app/signals.py", line 139, in testjob_notifications send_notifications(job) File "/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line 305, in send_notifications title, body, settings.SERVER_EMAIL, [recipient.email_address] File "/usr/lib/python3/dist-packages/django/core/mail/__init__.py", line 62, in send_mail return mail.send() File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line 342, in send return self.get_connection(fail_silently).send_messages([self]) File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 107, in send_messages sent = self._send(message) File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 120, in _send recipients = [sanitize_address(addr, encoding) for addr in email_message.recipients()] File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 120, in <listcomp> recipients = [sanitize_address(addr, encoding) for addr in email_message.recipients()] File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line 161, in sanitize_address address = Address(nm, addr_spec=addr) File "/usr/lib/python3.5/email/headerregistry.py", line 42, in __init__ a_s, rest = parser.get_addr_spec(addr_spec) File "/usr/lib/python3.5/email/_header_value_parser.py", line 1988, in get_addr_spec token, value = get_local_part(value) File "/usr/lib/python3.5/email/_header_value_parser.py", line 1800, in get_local_part if value[0] in CFWS_LEADER: IndexError: string index out of range 2018-12-04 14:14:40,211 INFO [EXIT] Disconnect logging socket and process messages 2018-12-04 14:14:40,211 DEBUG [EXIT] unbinding from 'tcp://0.0.0.0:5555' 2018-12-04 14:14:50,221 INFO [EXIT] Closing the logging socket: the queue is empty Regards

7 years, 4 months

3
6
0 0

non-posix (interactive) shell testing

by Milosz Wasilewski

Hi, I'm trying to experiment with 'interactive' test shell. The docs are here: https://master.lavasoftware.org/static/docs/v2/actions-test.html#index-1 As I understand the feature should work in the following way (the docs aren't very clear): 1. wait for one of the prompts 2. send command 3. match the result to regex (pass or fail) However when I try it out, there is no wait for prompt. LAVA immediately sends the command and adds value from prompts to list of expressions to match. Is this correct? Example job: https://staging.validation.linaro.org/scheduler/job/245886#L53 LAVA sends the command even before the board starts booting. Any help is appreciated. milosz

7 years, 4 months

3
4
0 0

U-Boot command sequence ignores prompt waiting

by Andrejs Cainikovs

Hi everyone, I’m facing an issue when U-Boot commands are sent one after another without waiting for a prompt. Obviously, device is not able to boot. Excerpt from logs: dhcp => dhcp bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56) setenv serverip 172.17.1.189 setenv serverip 172.17.1.189 bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56) tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56) tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55) setenv initrd_size ${filesize} setenv initrd_size ${filesize} bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55) tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55) dhcp dhcp link up on port 0, speed 10, half duplex BOOTP broadcast 1 setenv serverip 172.17.1.189 tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin BOOTP broadcast 2 tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot setenv initrd_size ${filesize} tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 Retry time exceeded setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' => setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:50) setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' => bootz 0x80000000 0x83000000 0x82000000 => bootz 0x80000000 0x83000000 0x82000000 bootloader-commands: Wait for prompt Starting kernel (timeout 00:04:50) bootz 0x80000000 0x83000000 0x82000000 bootz 0x80000000 0x83000000 0x82000000 Bad Linux ARM zImage magic! => Bad Linux ARM zImage magic! As you see, all commands that were sent between `dhcp` command and until it was able to complete or fail are simply dropped. Device type config: {% extends 'base-uboot.jinja2' %} {% set device_type = "vcu" %} {% set console_device = 'ttyS2' %} {% set baud_rate = 115200 %} {% set interrupt_prompt = 'Press s to abort autoboot' %} {% set interrupt_char = 's' %} {% set bootloader_prompt = '=>' %} {% set uboot_mkimage_arch = 'arm' %} {% set bootz_kernel_addr = '0x80000000' %} {% set bootz_ramdisk_addr = '0x83000000' %} {% set bootz_dtb_addr = '0x82000000' %} {% set extra_kernel_args = 'ti_cpsw.rx_packet_max=1526' %} {% set kernel_start_message = 'Welcome to' %} Device config: {% extends 'vcu.jinja2' %} {% set connection_command = 'telnet lava-disp-1.local 7000' %} {% set power_on_command = 'relay-ctrl --relay 1 --state on' %} {% set power_off_command = 'relay-ctrl --relay 1 --state off' %} {% set hard_reset_command = 'relay-ctrl --relay 1 --toggle' %} Boot action block from job definition: - boot: timeout: minutes: 5 method: u-boot commands: ramdisk auto_login: login_prompt: 'am335x-nmhw21 login: ' username: root prompts: - 'fct@am335x-nmhw21:~# ' Have I misconfigured something? What I’m missing? Thanks! Best regards, Andrejs Cainikovs.

7 years, 4 months

2
9
0 0

timeouts for test action not working

by Kevin Hilman

Hello, I have a LAVA job with long running test, so I put a timeout of 180 minutes in the test action itself[1]. However, but the job times out after 3989 seconds (~ 66 min)[2]. Looking closer at the "Timing" section of the job, I see that lava-test-shell indeed has a timeout of ~3989 seconds, but I have no idea where that number comes from. That's neither the 10 minutes in the default "timeouts" section, nor the 180 minutes I put in the "test" action. Hmm, after almost pushing send on this, I now seeing that in the "timeouts" sections, the whole job has a timeout of 70 minutes. So, I assume that means an absolute max, even if one of the actions puts a higher timeout? So I guess this email now turns into a feature request rather than a bug report. Maybe LAVA should show a warning at the top of the job if any of the actions has a timeout that's longer than the job timeout. Kevin [1] http://lava.baylibre.com:10080/scheduler/job/60374/definition#defline89 [2] http://lava.baylibre.com:10080/scheduler/job/60374#results_694663

7 years, 4 months

3
3
0 0

LAVA hacking session not starting

by Manoj Tiwary

Hi all, When I try to run a test in lava , hacking session is not starting . it is exiting by showing: Using /lava-18 export SHELL=/bin/sh # export SHELL=/bin/sh /lava-18/bin/lava-test-runner /lava-18/0 /lava-18/bin/lava-test-runner /lava-18/0 Test shell timeout: 10s (minimum of the action and connection timeout) export SHELL=/bin/sh # /lava-18/bin/lava-test-runner /lava-18/0 Illegal instruction <LAVA_TEST_RUNNER EXIT> ok: lava_test_shell seems to have completed end: 3.1 lava-test-shell (duration 00:00:01) [common] end: 3 lava-test-retry (duration 00:00:01) [common] start: 4 finalize (timeout 00:10:00) [common] start: 4.1 power-off (timeout 00:00:05) [common] end: 4.1 power-off (duration 00:00:00) [common] my board linux has busybox init system Please help me resolve the issue. I've attached the job log below. Thanks & Regards, Manoj

7 years, 4 months

2
1
0 0

Tradefed test definition modification

by Axel Lebourhis

Hi everyone, I'm currently running CTS tests on imx8mq on Android 9. My test job is based on Linaro's test definition located here : https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade… I had issue concerning the Java heap size, causing the test to abort and skip a lot of tests. So, I cloned this git tree and made modifications in "tradefed.sh" : export _JAVA_OPTIONS="-Xmx350M" replaced by : export _JAVA_OPTIONS="-Xmx700M" Since this modification, I'm able to run the full CTS 9. So, I think you should consider modify this script, so other users can benefit from it. Best regards, Axel

7 years, 4 months

2
8
0 0

setting u-boot bootargs

by Manoj Tiwary

Hi all, In Tftp deploy , How to give new set of u-boot bootargs by modifying device configuration file? I've tried by giving: {% set base_kernel_args = "setenv bootargs console=serial1,115200 console=tty1 root=/dev/ram0 ip=dhcp rootwait" %} But it is not taking these args. Please suggest the modifications I have to make. Thanks and regards, Manoj

7 years, 4 months

2
3
0 0

A question of LAVA's dead container.

by Li, Xiaoming

Hi Neil, When LAVA start container from image for the first time(usually docker run ), if failed, it will bring a zoobie container. And I found that LAVA did not check whether LAVA run is OK, and has no dead container cleanup method.(maybe I was wrong). Does LAVA have some method to prevent it or do you think it is necessary? Best Regards Li Xiaoming

7 years, 4 months

2
1
0 0

Reboot keyword mismatch

by Manoj Tiwary

Hi all, During send-reboot-commands phase in Health check on my raspberry pi 3 board, LAVA is trying to match the keyword "The system is going down for reboot NOW" after sending the reset command "reboot -n" to the DUT. But the problem is when my board starts Reboot it shows "Started Show Plymouth Reboot Screen .." , not the same as what LAVA want. So is there any way to specify the keywords to what it should be("Started Show Plymouth Reboot Screen" or something) in the corresponding DUTs jinja2 file? I've attached the reslult log of my test below. Regards, Manoj

7 years, 4 months

2
1
0 0

Problem with login in Web UI

by Axel Lebourhis

Hi everyone, I have some troubles to log in my Web UI. I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs. Best regards, Axel Le Bourhis

7 years, 5 months

2
13
0 0

default Soft reboot command

by Manoj Tiwary

Hi all, When health check is running on my raspberry pi 3 board , in boot phase it is taking default soft reboot commands like reboot , reboot -n , reboot -nf. which is not working with U-boot boot type. It is showing unknown command ' reboot' . How to set soft reboot command manually in test job definition? Thanks & regards, Manoj

7 years, 5 months

2
4
0 0

lava-server won't start

by Axel Lebourhis

Hi everyone, I got an issue using LAVA today. After trying to load a job page, LAVA crashed returning PROXY ERROR. I tried to restart lava-master, lava-slave and lava-server-gunicorn services without success. The django.log returns an error about django tables2, saying it can't find the module. I'm running LAVA 2018.10. See attached log for more precision. Best regards, Axel Le Bourhis

7 years, 5 months

2
2
0 0

Re: [Lava-users] Default LXC directory for LAVA

by Axel Lebourhis

Ok i'll keep that in mind. To mailing list : I confirm this solution fixed the issue. Kind regards, Axel On Tue, 6 Nov 2018 at 16:55, Neil Williams <neil.williams(a)linaro.org> wrote: > Yes, please always include the mailing list in replies. When people do > search for help in the list archives, it is frustrating to find the > question without the solution - or even just a confirmation that the > reply worked. > On Tue, 6 Nov 2018 at 15:47, Axel Lebourhis <axel.lebourhis(a)linaro.org> > wrote: > > > > Thank you for the clarification. I've been able to fix the problem > thanks to your help. > > > > Just a quick question : should I reply including the mailing list ? > > > > Regards, > > Axel > > > > On Tue, 6 Nov 2018 at 16:08, Neil Williams <neil.williams(a)linaro.org> > wrote: > >> > >> On Tue, 6 Nov 2018 at 14:59, Axel Lebourhis <axel.lebourhis(a)linaro.org> > wrote: > >> > > >> > Hi everyone, > >> > > >> > I just upgraded NXP's installation for DRM team from 2018.4 to > 2018.10. > >> > I changed my default LXC folder for storage purpose and when I was at > 2018.4, there was a constant.py file in > /usr/lib/python3/dist-packages/lava_dispatcher/utils in order to make LAVA > know where are located LXC containers. > >> > >> Avoid making code changes for these kinds of settings. Constants and > >> settings can be modified in configuration files. There is no need to > >> alter anything in /usr/lib/python3/dist-packages/lava* - any change > >> there will always be undone at the next package upgrade. > >> > >> > https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher.yaml#L13 > >> > >> So on a per-worker basis, you can set the LXC_PATH > >> > >> This support is covered under simple administration in the LAVA help: > >> > https://master.lavasoftware.org/static/docs/v2/simple-admin.html#lava-server > >> > >> In 2018.10 release, this file doesn't exist anymore, so I'd like to > >> know how I can specify to LAVA the correct path to LXC containers. > >> > > >> > Best regards, > >> > Axel Le Bourhis > >> > > >> > _______________________________________________ > >> > Lava-users mailing list > >> > Lava-users(a)lists.lavasoftware.org > >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users > >> > >> > >> > >> -- > >> > >> Neil Williams > >> ============= > >> neil.williams(a)linaro.org > >> http://www.linux.codehelp.co.uk/ > > > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/ >

7 years, 5 months

1
0
0 0

Default LXC directory for LAVA

by Axel Lebourhis

Hi everyone, I just upgraded NXP's installation for DRM team from 2018.4 to 2018.10. I changed my default LXC folder for storage purpose and when I was at 2018.4, there was a constant.py file in /usr/lib/python3/dist-packages/lava_dispatcher/utils in order to make LAVA know where are located LXC containers. In 2018.10 release, this file doesn't exist anymore, so I'd like to know how I can specify to LAVA the correct path to LXC containers. Best regards, Axel Le Bourhis

7 years, 5 months

2
1
0 0

LAVA API add health-check issue

by Patryk Mungai Ndungu

Hello, I am having an issue adding a health-check job for a device-type using the API. I have tried doing so using both lavacli and through a python script using the xml-rpc client, but both times I get the following error: With lavacli: Unable to call 'device-types.health-check': <Fault 400: 'Unable to write health-check: Permission denied'> With the python script: Traceback (most recent call last): File "./API.py", line 9, in <module> server.scheduler.device_types.set_health_check("r8a7743-iwg20d-q7-dbcm-ca","r8a7743-iwg20d-q7-dbcm-ca.yaml") File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__ return self.__send(self.__name, args) File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request verbose=self.__verbose File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1150, in single_request return self.parse_response(resp) File "/usr/lib/python3.5/xmlrpc/client.py", line 1322, in parse_response return u.close() File "/usr/lib/python3.5/xmlrpc/client.py", line 655, in close raise Fault(**self._stack[0]) xmlrpc.client.Fault: <Fault 400: 'Unable to write health-check: Permission denied'> The user I use to authenticate the xml-rpc client has superuser privileges and I have tried using a number of different API functions (including ones which require superuser privileges like device-types add and devices add), all of which have worked with both lavacli and the python script. I have also made sure that the name of the healthcheck file matches the device-type. Has anyone else encountered this issue? Thanks, Patryk Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

7 years, 5 months

3
5
0 0

adding devices in LAVA docker

by Manoj Tiwary

Hi all, I've installed lava-docker from https://github.com/kernelci/lava-docker but I'm little confused about adding devices and device-types to it . As described in the link above , i've edited boards.yaml file and added the board name as follows masters: - name: master1 host: local users: - name: admin token: longrandomtokenadmin password: admin superuser: yes staff: yes tokens: - username: admin token: dfjdfkfkdjfkdsjfsl description: no description slaves: - name: lab-slave-0 host: local remote_master: master1 remote_user: admin boards: - name: bcm2837-rpi-3-b-01 type: bcm2837-rpi-3-b uart: idvendor: 0x0403 idproduct: 0x6001 serial: A904MHLH after I built docker image and ran it. i'm getting following error while loading docker images Removing local_lab-slave-0_1 local_master1_1 is up-to-date Recreating 5b8d2c91c519_local_lab-slave-0_1 ... error ERROR: for 5b8d2c91c519_local_lab-slave-0_1 Cannot start service lab-slave-0: linux runtime spec devices: error gathering device information while adding custom device "/dev/bcm2837-rpi-3-b-01": lstat /dev/bcm2837-rpi-3-b-01: no such file or directory ERROR: for lab-slave-0 Cannot start service lab-slave-0: linux runtime spec devices: error gathering device information while adding custom device "/dev/bcm2837-rpi-3-b-01": lstat /dev/bcm2837-rpi-3-b-01: no such file or directory help me resolve this issue. Thanks, Manoj

7 years, 5 months

2
3
0 0

Fwd: regarding test suites

by Hemanth K V

Hello Lava-users, I am trying to run some test suites in LAVA and my test suite is organized as below -single script with multiple test cases -want to have report the results from LAVA of all test cases -don't want to depend on the return value of script which will make as test case as PASS or FAIL Developing test suites in shell script and using sh-test-lib and attached is sample test script for reference. Want to report the result of iptable_packageCheck_test and iptable_kernel_config_test separately in LAVA framework and will be having single script for both the test cases. Based on above criteria which is best method of running the test script in LAVA.Referred https://validation.linaro.org/static/docs/v2/developing-tests.html Following is the content of LAVA Test Shell Definition I am using metadata: name: applications format: "Lava-Test-Shell Test Definition 1.0" description: "Application tests." os: - debian scope: - Functional environment: - lava-test-shell run: steps: - cd /opt/applications - ./cron.sh - ./iptable.sh - . ../utils/send-to-lava.sh output/result.txt Thanks, Hemanth.

7 years, 5 months

3
2
0 0

Fwd: Issue in adding Device type

by Manoj Tiwary

---------- Forwarded message --------- From: Manoj Tiwary <manojtiwary22(a)gmail.com> Date: Thu 25 Oct, 2018, 6:46 PM Subject: Issue in adding Device type To: <lava-users(a)lists.linaro.org> Hi all, I've installed lava on Ubuntu 14.04 by following below steps : *deb [arch=amd64] http://images.validation.linaro.org/trusty-repo <http://images.validation.linaro.org/trusty-repo> trusty main$ wget http://images.validation.linaro.org/trusty-repo/trusty-repo.key.asc <http://images.validation.linaro.org/trusty-repo/trusty-repo.key.asc>$ sudo apt-key add trusty-repo.key.asc$ sudo apt-get update$ sudo apt-get install lava-server$ sudo a2dissite 000-default$ sudo a2ensite lava-server.conf$ sudo service apache2 restart* Now when i'm trying to add device-type using following command *$ sudo lava-server manage add-device-type qemu* I'm getting command not found error. so , I checked subcommands available using *$ sudo lava-server manage help * I got following output Available subcommands: [auth] changepassword createsuperuser [dashboard_app] addldapuser authorize_superuser linaro_ldapuserlist mergeldapuser [django] check cleanup compilemessages createcachetable dbshell diffsettings dumpdata flush inspectdb loaddata makemessages runfcgi shell sql sqlall sqlclear sqlcustom sqldropindexes sqlflush sqlindexes sqlinitialdata sqlsequencereset startapp startproject validate [django_extensions] clean_pyc compile_pyc create_app create_command create_jobs describe_form dumpscript export_emails find_template generate_secret_key graph_models mail_debug notes passwd pipchecker print_settings print_user_for_session reset_db runjob runjobs runprofileserver runscript runserver_plus set_fake_emails set_fake_passwords shell_plus show_templatetags show_urls sqlcreate sqldiff sync_media_s3 sync_s3 syncdata unreferenced_files update_permissions validate_templates [django_openid_auth] openid_cleanup [lava_scheduler_app] crowd device-dictionary dispatcher-master migrate-users-to-crowd scheduler schedulermonitor testjobmigrate [sessions] clearsessions [south] convert_to_south datamigration graphmigrations migrate migrationcheck schemamigration startmigration syncdb test testserver [staticfiles] collectstatic findstatic runserver add-device-type subcommand is not there. Help me resolve this issue. Thanks & Regards, Manoj

7 years, 5 months

2
1
0 0

Re: [Lava-users] Overwriting SERVER_IP

by Patryk Mungai Ndungu

Hello, Is there a way to overwrite the SERVER_IP variable either in the LAVA environment or in the device-types template/device dictionary? https://lava.ciplatform.org/static/docs/v2/migrating-admin-example.html?hig… No matter what I do, it remains in the rendered yaml file for a device. Unfortunately, the IP it picks up for the environment I'm working is wrong, as I'm running LAVA within a docker-container and it picks up the IP of the container, but the tftp server (within docker) is proxified to the host, meaning that the IP address it needs to pick up is the host's IP. Hence my question, is there a way to overwrite it so that the desired IP appears in the rendered job submission yaml? Thanks, Patryk Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

7 years, 5 months

2
2
0 0

lavacli: adding remote worker requires superuser

by Kevin Hilman

Hello, When trying to use lavacli to add a remote worker, it works fine if the user is a superuser. However, if I drop the superuser privileges and add just the privileges for adding workers, it fails with: Unable to call 'workers.add': <Fault 403: "User 'testuser' is not superuser." we even tried enabling all the permissions for that user, but leaving the superuser flag off, and it still fails. Why does this require superuser and the specific permissions related to workers don't work? Kevin

7 years, 5 months

4
8
0 0

job stuck after disconnection

by Corentin Labbe

Hello We got a job (number 332) stuck in running state. After 23h of inaction, the only way to stop it was to cancel+fail it. According to the logs, a small disconnection happen between the slave and master. The slave seems to try to update the final status of the job but the master "ignore" it. Regards This is the slave logs: 2018-09-21 21:45:57,197 INFO [332] Starting job2018-09-21 21:45:57,226 DEBUG [332] device : actions: 2018-09-21 21:45:57,227 DEBUG [332] env-dut : 2018-09-21 21:45:57,241 DEBUG START_OK(332) => master 2018-09-21 21:46:17,260 DEBUG PING => master (last message 20s ago) 2018-09-21 21:46:17,453 DEBUG master => PONG(20) 2018-09-21 21:46:37,475 DEBUG PING => master (last message 20s ago) 2018-09-21 21:46:37,684 DEBUG master => PONG(20) 2018-09-21 21:46:57,708 DEBUG PING => master (last message 20s ago) 2018-09-21 21:47:03,603 DEBUG master => PONG(20) 2018-09-21 21:47:23,625 DEBUG PING => master (last message 20s ago) 2018-09-21 21:47:41,199 DEBUG master => PONG(20) 2018-09-21 21:48:01,222 DEBUG PING => master (last message 20s ago) 2018-09-21 21:48:19,372 DEBUG master => PONG(20) ## 2018-09-21 21:48:39,395 DEBUG PING => master (last message 20s ago) ## 2018-09-21 21:48:59,418 DEBUG PING => master (last message 40s ago) ## 2018-09-21 21:49:19,441 DEBUG PING => master (last message 60s ago) 2018-09-21 21:49:34,458 INFO [332] Job END ## 2018-09-21 21:49:34,487 DEBUG END(332) => master 2018-09-21 21:49:39,496 WARNING Master goes OFFLINE 2018-09-21 21:49:39,496 DEBUG PING => master (last message 80s ago) 2018-09-21 21:49:39,501 INFO [332] Job END (resend) 2018-09-21 21:49:39,515 DEBUG END(332) => master 2018-09-21 21:49:44,521 INFO [332] Job END (resend) 2018-09-21 21:49:44,538 DEBUG END(332) => master 2018-09-21 21:49:49,544 INFO [332] Job END (resend) 2018-09-21 21:49:49,559 DEBUG END(332) => master 2018-09-21 21:49:54,565 INFO [332] Job END (resend) 2018-09-21 21:49:54,588 DEBUG END(332) => master 2018-09-21 21:49:59,594 DEBUG PING => master (last message 100s ago) 2018-09-21 21:49:59,594 INFO [332] Job END (resend) 2018-09-21 21:49:59,612 DEBUG END(332) => master 2018-09-21 21:50:04,618 INFO [332] Job END (resend) 2018-09-21 21:50:04,639 DEBUG END(332) => master 2018-09-21 21:50:09,645 INFO [332] Job END (resend) 2018-09-21 21:50:09,659 DEBUG END(332) => master 2018-09-21 21:50:14,665 INFO [332] Job END (resend) 2018-09-21 21:50:14,685 DEBUG END(332) => master 2018-09-21 21:50:19,690 DEBUG PING => master (last message 120s ago) 2018-09-21 21:50:19,691 INFO [332] Job END (resend) 2018-09-21 21:50:19,708 DEBUG END(332) => master 2018-09-21 21:50:24,714 INFO [332] Job END (resend) 2018-09-21 21:50:24,735 DEBUG END(332) => master 2018-09-21 21:50:29,741 INFO [332] Job END (resend) 2018-09-21 21:50:29,755 DEBUG END(332) => master 2018-09-21 21:50:34,761 INFO [332] Job END (resend) 2018-09-21 21:50:34,776 DEBUG END(332) => master 2018-09-21 21:50:39,781 DEBUG PING => master (last message 140s ago) 2018-09-21 21:50:39,782 INFO [332] Job END (resend) 2018-09-21 21:50:39,800 DEBUG END(332) => master 2018-09-21 21:50:44,806 INFO [332] Job END (resend) 2018-09-21 21:50:44,823 DEBUG END(332) => master 2018-09-21 21:50:49,829 INFO [332] Job END (resend) 2018-09-21 21:50:49,850 DEBUG END(332) => master 2018-09-21 21:50:54,856 INFO [332] Job END (resend) 2018-09-21 21:50:54,876 DEBUG END(332) => master 2018-09-21 21:50:59,882 DEBUG PING => master (last message 160s ago) 2018-09-21 21:50:59,883 INFO [332] Job END (resend) 2018-09-21 21:50:59,901 DEBUG END(332) => master 2018-09-21 21:51:04,907 INFO [332] Job END (resend) 2018-09-21 21:51:04,920 DEBUG END(332) => master 2018-09-21 21:51:09,926 INFO [332] Job END (resend) 2018-09-21 21:51:09,939 DEBUG END(332) => master 2018-09-21 21:51:14,945 INFO [332] Job END (resend) 2018-09-21 21:51:14,967 DEBUG END(332) => master 2018-09-21 21:51:19,973 DEBUG PING => master (last message 180s ago) 2018-09-21 21:51:19,974 INFO [332] Job END (resend) 2018-09-21 21:51:19,994 DEBUG END(332) => master 2018-09-21 21:51:25,000 INFO [332] Job END (resend) 2018-09-21 21:51:25,020 DEBUG END(332) => master 2018-09-21 21:51:30,026 INFO [332] Job END (resend) 2018-09-21 21:51:30,047 DEBUG END(332) => master 2018-09-21 21:51:35,053 INFO [332] Job END (resend) 2018-09-21 21:51:35,071 DEBUG END(332) => master 2018-09-21 21:51:40,077 DEBUG PING => master (last message 200s ago) 2018-09-21 21:51:40,077 INFO [332] Job END (resend) 2018-09-21 21:51:40,095 DEBUG END(332) => master 2018-09-21 21:51:45,101 INFO [332] Job END (resend) 2018-09-21 21:51:45,123 DEBUG END(332) => master 2018-09-21 21:51:50,129 INFO [332] Job END (resend) 2018-09-21 21:51:50,149 DEBUG END(332) => master 2018-09-21 21:51:55,154 INFO [332] Job END (resend) 2018-09-21 21:51:55,175 DEBUG END(332) => master 2018-09-21 21:51:58,639 DEBUG master => PONG(20) 2018-09-21 21:51:58,640 INFO Master is ONLINE 2018-09-21 21:51:58,831 DEBUG master => PONG(20) 2018-09-21 21:51:58,833 DEBUG master => PONG(20) 2018-09-21 21:52:00,053 INFO master => END_OK(332) 2018-09-21 21:52:00,054 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,062 DEBUG master => PONG(20) 2018-09-21 21:52:00,062 INFO master => END_OK(332) 2018-09-21 21:52:00,063 DEBUG [332] Unknown job 2018-09-21 21:52:00,063 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,242 INFO master => END_OK(332) 2018-09-21 21:52:00,242 DEBUG [332] Unknown job 2018-09-21 21:52:00,243 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,243 INFO master => END_OK(332) 2018-09-21 21:52:00,244 DEBUG [332] Unknown job 2018-09-21 21:52:00,244 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,244 INFO master => END_OK(332) 2018-09-21 21:52:00,245 DEBUG [332] Unknown job 2018-09-21 21:52:00,245 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,246 DEBUG master => PONG(20) 2018-09-21 21:52:00,246 INFO master => END_OK(332) 2018-09-21 21:52:00,246 DEBUG [332] Unknown job 2018-09-21 21:52:00,246 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,381 INFO master => END_OK(332) 2018-09-21 21:52:00,382 DEBUG [332] Unknown job 2018-09-21 21:52:00,382 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,436 INFO master => END_OK(332) 2018-09-21 21:52:00,436 DEBUG [332] Unknown job 2018-09-21 21:52:00,436 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,592 INFO master => END_OK(332) 2018-09-21 21:52:00,593 DEBUG [332] Unknown job 2018-09-21 21:52:00,593 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,610 DEBUG master => PONG(20) 2018-09-21 21:52:00,770 INFO master => END_OK(332) 2018-09-21 21:52:00,771 DEBUG [332] Unknown job 2018-09-21 21:52:00,771 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,892 INFO master => END_OK(332) 2018-09-21 21:52:00,892 DEBUG [332] Unknown job 2018-09-21 21:52:00,892 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,976 INFO master => END_OK(332) 2018-09-21 21:52:00,977 DEBUG [332] Unknown job 2018-09-21 21:52:00,977 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,156 INFO master => END_OK(332) 2018-09-21 21:52:01,157 DEBUG [332] Unknown job 2018-09-21 21:52:01,157 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,164 DEBUG master => PONG(20) 2018-09-21 21:52:01,170 INFO master => END_OK(332) 2018-09-21 21:52:01,171 DEBUG [332] Unknown job 2018-09-21 21:52:01,171 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,353 INFO master => END_OK(332) 2018-09-21 21:52:01,353 DEBUG [332] Unknown job 2018-09-21 21:52:01,353 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,493 INFO master => END_OK(332) 2018-09-21 21:52:01,493 DEBUG [332] Unknown job 2018-09-21 21:52:01,493 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,550 INFO master => END_OK(332) 2018-09-21 21:52:01,551 DEBUG [332] Unknown job 2018-09-21 21:52:01,551 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,552 DEBUG master => PONG(20) 2018-09-21 21:52:01,700 INFO master => END_OK(332) 2018-09-21 21:52:01,700 DEBUG [332] Unknown job 2018-09-21 21:52:01,700 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,745 INFO master => END_OK(332) 2018-09-21 21:52:01,745 DEBUG [332] Unknown job 2018-09-21 21:52:01,745 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,819 INFO master => END_OK(332) 2018-09-21 21:52:01,819 DEBUG [332] Unknown job 2018-09-21 21:52:01,820 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,936 INFO master => END_OK(332) 2018-09-21 21:52:01,936 DEBUG [332] Unknown job 2018-09-21 21:52:01,936 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,938 DEBUG master => PONG(20) 2018-09-21 21:52:02,048 INFO master => END_OK(332) 2018-09-21 21:52:02,048 DEBUG [332] Unknown job 2018-09-21 21:52:02,049 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:02,138 INFO master => END_OK(332) 2018-09-21 21:52:02,138 DEBUG [332] Unknown job 2018-09-21 21:52:02,138 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:22,160 DEBUG PING => master (last message 20s ago) 2018-09-21 21:52:37,178 INFO master => END_OK(332) 2018-09-21 21:52:37,179 DEBUG [332] Unknown job 2018-09-21 21:52:37,179 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:37,180 INFO master => END_OK(332) 2018-09-21 21:52:37,180 DEBUG [332] Unknown job 2018-09-21 21:52:37,180 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:37,181 DEBUG master => PONG(20) 2018-09-21 21:52:37,181 INFO master => END_OK(332) 2018-09-21 21:52:37,181 DEBUG [332] Unknown job 2018-09-21 21:52:37,182 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:37,374 DEBUG master => PONG(20) 2018-09-21 21:52:57,396 DEBUG PING => master (last message 20s ago) 2018-09-21 21:53:17,418 DEBUG PING => master (last message 40s ago) 2018-09-21 21:53:21,421 DEBUG master => PONG(20) 2018-09-21 21:53:21,610 DEBUG master => PONG(20) 2018-09-21 21:53:41,632 DEBUG PING => master (last message 20s ago) 2018-09-21 21:54:01,653 DEBUG PING => master (last message 40s ago) 2018-09-21 21:54:05,695 DEBUG master => PONG(20) 2018-09-21 21:54:05,893 DEBUG master => PONG(20) 2018-09-21 21:54:25,911 DEBUG PING => master (last message 20s ago) 2018-09-21 21:54:45,933 DEBUG PING => master (last message 40s ago) 2018-09-21 21:54:51,497 DEBUG master => PONG(20) 2018-09-21 21:54:51,692 DEBUG master => PONG(20) 2018-09-21 21:55:11,713 DEBUG PING => master (last message 20s ago) 2018-09-21 21:55:31,733 DEBUG PING => master (last message 40s ago) 2018-09-21 21:55:38,958 DEBUG master => PONG(20) 2018-09-21 21:55:39,147 DEBUG master => PONG(20) 2018-09-21 21:55:59,169 DEBUG PING => master (last message 20s ago) 2018-09-21 21:56:19,191 DEBUG PING => master (last message 40s ago) 2018-09-21 21:56:23,724 DEBUG master => PONG(20) 2018-09-21 21:56:23,927 DEBUG master => PONG(20) 2018-09-21 21:56:43,950 DEBUG PING => master (last message 20s ago) 2018-09-21 21:56:44,137 DEBUG master => PONG(20) 2018-09-21 21:57:04,159 DEBUG PING => master (last message 20s ago) 2018-09-21 21:57:04,351 DEBUG master => PONG(20) And this is the master logs: 2018-09-21 21:45:56,427 INFO scheduling jobs: 2018-09-21 21:45:56,428 DEBUG - bcm2837-rpi-3-b-32 2018-09-21 21:45:56,453 DEBUG -> rpi3-corelab-01 (Idle, Good) 2018-09-21 21:45:56,453 DEBUG |--> [332] scheduling 2018-09-21 21:45:56,459 DEBUG - dra7-evm 2018-09-21 21:45:56,464 DEBUG - qemu 2018-09-21 21:45:56,660 INFO [332] START => agl-core-lab-1 (rpi3-corelab-01) 2018-09-21 21:45:57,341 INFO [332] agl-core-lab-1 => START_OK 2018-09-21 21:45:57,773 DEBUG lava-logs => PING(20) 2018-09-21 21:46:16,711 INFO scheduling health checks: 2018-09-21 21:46:16,724 INFO scheduling jobs: 2018-09-21 21:46:16,725 DEBUG - dra7-evm 2018-09-21 21:46:16,729 DEBUG - qemu 2018-09-21 21:46:17,351 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:46:18,980 DEBUG lava-logs => PING(20) 2018-09-21 21:46:36,744 INFO scheduling health checks: 2018-09-21 21:46:36,757 INFO scheduling jobs: 2018-09-21 21:46:36,758 DEBUG - dra7-evm 2018-09-21 21:46:36,762 DEBUG - qemu 2018-09-21 21:46:37,566 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:46:48,466 DEBUG lava-logs => PING(20) 2018-09-21 21:46:56,776 INFO scheduling health checks: 2018-09-21 21:46:56,790 INFO scheduling jobs: 2018-09-21 21:46:56,791 DEBUG - dra7-evm 2018-09-21 21:46:56,795 DEBUG - qemu 2018-09-21 21:46:57,797 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:47:08,482 DEBUG lava-logs => PING(20) 2018-09-21 21:47:16,809 INFO scheduling health checks: 2018-09-21 21:47:16,822 INFO scheduling jobs: 2018-09-21 21:47:16,823 DEBUG - dra7-evm 2018-09-21 21:47:16,827 DEBUG - qemu 2018-09-21 21:47:23,718 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:47:31,521 DEBUG lava-logs => PING(20) 2018-09-21 21:47:36,841 INFO scheduling health checks: 2018-09-21 21:47:36,854 INFO scheduling jobs: 2018-09-21 21:47:36,855 DEBUG - dra7-evm 2018-09-21 21:47:36,859 DEBUG - qemu 2018-09-21 21:47:54,275 DEBUG lava-logs => PING(20) 2018-09-21 21:47:56,872 INFO scheduling health checks: 2018-09-21 21:47:56,885 INFO scheduling jobs: 2018-09-21 21:47:56,886 DEBUG - dra7-evm 2018-09-21 21:47:56,891 DEBUG - qemu 2018-09-21 21:48:01,321 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:48:14,292 DEBUG lava-logs => PING(20) 2018-09-21 21:48:16,903 INFO scheduling health checks: 2018-09-21 21:48:16,917 INFO scheduling jobs: 2018-09-21 21:48:16,918 DEBUG - dra7-evm 2018-09-21 21:48:16,922 DEBUG - qemu 2018-09-21 21:48:35,995 DEBUG lava-logs => PING(20) 2018-09-21 21:48:36,933 INFO scheduling health checks: 2018-09-21 21:48:36,946 INFO scheduling jobs: 2018-09-21 21:48:36,947 DEBUG - dra7-evm 2018-09-21 21:48:36,951 DEBUG - qemu 2018-09-21 21:48:39,486 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:48:56,011 DEBUG lava-logs => PING(20) 2018-09-21 21:48:56,962 INFO scheduling health checks: 2018-09-21 21:48:56,975 INFO scheduling jobs: 2018-09-21 21:48:56,976 DEBUG - dra7-evm 2018-09-21 21:48:56,981 DEBUG - qemu 2018-09-21 21:49:16,995 INFO scheduling health checks: 2018-09-21 21:49:17,009 INFO scheduling jobs: 2018-09-21 21:49:17,010 DEBUG - dra7-evm 2018-09-21 21:49:17,014 DEBUG - qemu 2018-09-21 21:49:21,406 DEBUG lava-logs => PING(20) 2018-09-21 21:49:37,026 INFO scheduling health checks: 2018-09-21 21:49:37,040 INFO scheduling jobs: 2018-09-21 21:49:37,041 DEBUG - dra7-evm 2018-09-21 21:49:37,046 DEBUG - qemu 2018-09-21 21:49:41,419 DEBUG lava-logs => PING(20) 2018-09-21 21:49:52,363 ERROR [STATE] Dispatcher <agl-core-lab-1> goes OFFLINE 2018-09-21 21:49:57,059 INFO scheduling health checks: 2018-09-21 21:49:57,067 INFO scheduling jobs: 2018-09-21 21:50:01,440 DEBUG lava-logs => PING(20) 2018-09-21 21:50:17,078 INFO scheduling health checks: 2018-09-21 21:50:17,086 INFO scheduling jobs: 2018-09-21 21:50:21,462 DEBUG lava-logs => PING(20) 2018-09-21 21:50:37,097 INFO scheduling health checks: 2018-09-21 21:50:37,105 INFO scheduling jobs: 2018-09-21 21:50:41,484 DEBUG lava-logs => PING(20) 2018-09-21 21:50:57,117 INFO scheduling health checks: 2018-09-21 21:50:57,125 INFO scheduling jobs: 2018-09-21 21:51:01,502 DEBUG lava-logs => PING(20) 2018-09-21 21:51:17,135 INFO scheduling health checks: 2018-09-21 21:51:17,144 INFO scheduling jobs: 2018-09-21 21:51:21,524 DEBUG lava-logs => PING(20) 2018-09-21 21:51:37,154 INFO scheduling health checks: 2018-09-21 21:51:37,162 INFO scheduling jobs: 2018-09-21 21:51:41,546 DEBUG lava-logs => PING(20) 2018-09-21 21:51:57,170 INFO scheduling health checks: 2018-09-21 21:51:57,178 INFO scheduling jobs: 2018-09-21 21:51:58,734 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:51:58,737 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:51:59,125 INFO [332] agl-core-lab-1 => END 2018-09-21 21:51:59,954 DEBUG get_type_name: skipping finalize 2018-09-21 21:51:59,954 DEBUG type_name failed for finalize metatype finalize 2018-09-21 21:51:59,954 DEBUG get_type_name: skipping finalize 2018-09-21 21:51:59,954 DEBUG type_name failed for finalize metatype finalize 2018-09-21 21:51:59,954 DEBUG get_type_name: skipping finalize 2018-09-21 21:51:59,954 DEBUG type_name failed for finalize metatype finalize 2018-09-21 21:51:59,960 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:51:59,964 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,968 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,971 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,974 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,977 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:00,093 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,287 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,341 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,493 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,496 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:00,674 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,795 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,881 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,061 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,063 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:01,075 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,256 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,397 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,453 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,456 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:01,568 DEBUG lava-logs => PING(20) 2018-09-21 21:52:01,603 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,646 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,722 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,840 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,842 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:01,884 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,985 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:02,040 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:02,106 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:02,109 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:02,220 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:17,187 INFO scheduling health checks: 2018-09-21 21:52:17,201 INFO scheduling jobs: 2018-09-21 21:52:17,202 DEBUG - dra7-evm 2018-09-21 21:52:17,207 DEBUG - qemu 2018-09-21 21:52:21,585 DEBUG lava-logs => PING(20)

7 years, 5 months

4
4
0 0

REST API

by Milosz Wasilewski

Hi, I made a first attempt to add REST API for some LAVA objects (jobs, devices and device types). The API is very rudimentary but already solves some basic job filtering issues. However I'm not sure how to add dependencies. There are 2 packages required for this code to work properly. Pip packages are named 'djangorestframework' and 'djangorestframework-filters'. Former has a corresponding debian package 'python3-djangorestframework' but the later does not. Any hints how to add proper dependencies to LAVA? The code can be found here: https://git.lavasoftware.org/mwasilew/lava/tree/rest_api milosz

7 years, 5 months

2
12
0 0

Integrate auxiliary device in LAVA test job definition

by Oana Ercus

Hello, I am looking for a suitable method for the following use-case: during test, I need to access the connection to the workstation that runs my LAVA worker and use it as a second namespace in order to be able to issue some commands on the the workstation (like playing an audio file). In other words I need to integrate the workstation as an auxiliary device needed for testing in the test job definition (like ssh <user>@<ws_ip_addr> and send some commands). Using LXC is not an option at this moment. At a first sight, the Multinode support would have the most of the needed features, but I did not find an example of such an usage, if there is any example you can point me to, I will be grateful. Thank you in advance, Oana Ercus

7 years, 6 months

2
1
0 0

Setting tags for existing devices via command line

by Tim Jaacks

Hello everyone, is there a way of setting tags for existing devices via the command line? The "lava-server manage devices update" command does not have a "--tags" parameter, as the "lava-server manage devices add" has. 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 6 months

2
3
0 0

Does deploy action have such as "deploy-namespace" to indicate to use previous deploy images?

by john zhang

In lava job definition, boot action can use "connection-namespace" to indicate use previous namespace's connection.Does deploy action have such as "deploy-namespace" to indicate to use previous deploy image? For example in an application scenario, it need to sequential execution two phases pipeline(deploy,boot,test), it can be solved by define two namespace in job definiton. When run it executed in serial as : phase1(namespace1) deploy->boot->test -> phase2(namespace2) deploy->boot->test. If phase2 deploy images(kernel,dtb,rootfs) are exactly same as phase2 deploy images,how to speed up phase2 deploy execution? I guess if deploy action have such as "deploy-namespace" to indicate previous deploy,then phase2 deploy process can be pass.

7 years, 6 months

2
7
0 0

In job defintion file the description of the related device is only the "device_type", why is not "device"?

by john zhang

Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/. The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device. When the dispatcher submits job, a job should be submited to a concrete device.But In job defintion file,the description of the related device is only the "device_type" but no "device", why is not "device"? for example: # Your first LAVA JOB definition for arm device_type: arm job_name: arm pipeline, first job ## why not as: # Your first LAVA JOB definition for arm device: arm01 job_name: arm pipeline, first job

7 years, 6 months

3
6
0 0

does LXC devices mean LXC can emulate various arm devices peripheral interfaces?

by chao yang

https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html#lxc-depl… , It say that LXC devices can run lava tests within a container without disturbing the dispatcher host. Does LXC support the arm device? Although LXC may supports to run the arm virtual machine in PC server,but how does it support the completed arm device(Including various peripheral interfaces eg ethernet,usb.. ) ? Because the test job often test various peripheral interfaces,Is LXC emulating these interfaces?

7 years, 6 months

2
4
0 0

Getting tests on DUT: other solutions?

by Diego Russo

Hello, Currently I'm testing a board type which deploys OE via u-boot-ums. Before flashing the image into the device, LAVA slave modifies the image copying tests definition onto it. Once the image is modified with all the tests, this is dd'ed into the device, booted and tests will be running. This is OK so far but as soon as we enable signed images (roofs will be R/O but we will be having other R/W partitions) this won't work anymore as we are changing the image and it needs to be resigned. Moreover, this is very board specific. I'm here to investigate alternative solutions which have a more "generic" approach which also a developer (without LAVA) can run. The only assumption is that *the DUT has always wired network connectivity with the SLAVE*. The workflow I have in mind is something like: 1) I have a signed image which I deploy onto the DUT 2) Boot the DUT 3) Instruct the device to get tests from somewhere (either from the SLAVE or internet) 4) Run those tests The step I'd like to solve is 3). I was thinking something like that: * download/compile all I need on the SLAVE (it is not possible to do it on the DUT due to limited resources/libraries/tooling) * setup some sort of server http on the SLAVE in order to serve those files * wget those files onto the DUT * setup and execute the tests. The above approach should work WITHOUT LAVA as well. Basically, replace SLAVE with "developer computer" Is it something I can architect with LAVA? Does LAVA give me this flexibility? Thanks for your help Regards -- Diego Russo Staff Software Engineer - diego.russo(a)arm.com Direct Tel. no: +44 1223 405920 Main Tel. no: +44 1223 400400 ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - http://twitter.com/diegor http://www.linkedin.com/in/diegor IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

7 years, 6 months

2
4
0 0

Re: [Lava-users] Description of LAVA's user permissions

by Tim Jaacks

>On Mon, 8 Oct 2018 at 10:19, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote: > >> Hello everyone, >> >> is there a detailed description for all the user permissions defined by >> LAVA? Or where do I find them in the source code? >> > >LAVA currently only has one level of permissions - superuser or not. > >There is on custom permission - cancel or resubmit test job. > >Everything else comes from Django and is ignored. > At least the "Can add test job" permission seems to be evaluated as well. The UI element "Scheduler -> Submit" is available only if this permission is set. > >> >> There are lots of permissions of which I have no idea what they mean, e.g. >> "Can [add|change|delete] action data". How is this permission used? >> >> 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 at garz-fricke.com >> www.garz-fricke.com >> SOLUTIONS THAT COMPLETE! >> >> Sitz der Gesellschaft: D-21079 Hamburg >> Registergericht: Amtsgericht Hamburg, HRB 60514 >> Geschäftsführer: Matthias Fricke, Manfred Garz >> >> _______________________________________________ >> Lava-users mailing list >> Lava-users at lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lava-users >> > > >-- > >Neil Williams >============= >neil.williams at linaro.org >http://www.linux.codehelp.co.uk/ >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20181008/bf5abb68/…> 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 6 months

1
0
0 0

Re: [Lava-users] Description of LAVA's user permissions

by Tim Jaacks

>On Mon, 8 Oct 2018 at 10:19, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote: > >> Hello everyone, >> >> is there a detailed description for all the user permissions defined by >> LAVA? Or where do I find them in the source code? >> > >LAVA currently only has one level of permissions - superuser or not. > >There is on custom permission - cancel or resubmit test job. > >Everything else comes from Django and is ignored. > Oh thanks, I didn't know that. Is this noted anywhere in the docs? > >> >> There are lots of permissions of which I have no idea what they mean, e.g. >> "Can [add|change|delete] action data". How is this permission used? >> >> 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 at garz-fricke.com >> www.garz-fricke.com >> SOLUTIONS THAT COMPLETE! >> >> Sitz der Gesellschaft: D-21079 Hamburg >> Registergericht: Amtsgericht Hamburg, HRB 60514 >> Geschäftsführer: Matthias Fricke, Manfred Garz >> >> _______________________________________________ >> Lava-users mailing list >> Lava-users at lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lava-users >> > > >-- > >Neil Williams >============= >neil.williams at linaro.org >http://www.linux.codehelp.co.uk/ >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20181008/bf5abb68/…> 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 6 months

1
0
0 0

Description of LAVA's user permissions

by Tim Jaacks

Hello everyone, is there a detailed description for all the user permissions defined by LAVA? Or where do I find them in the source code? There are lots of permissions of which I have no idea what they mean, e.g. "Can [add|change|delete] action data". How is this permission used? 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 6 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users