linaro-validation

linaro-validation@lists.linaro.org

818 discussions

by Botao Sun

Hi, I'm recently working on some test cases which involve the measurement, but have no idea how to handle it after several failures occurred. For example: https://validation.linaro.org/scheduler/job/126298 <LAVA_SIGNAL_STARTRUN fio-ubuntu db652397-5831-4cc3-b2b3-1246879ac696> echo LAVA_ACK /root test_case_id:fio_device_existence result:PASS which fio The FIO binary location is: /usr/bin/fio test_case_id:fio_existence result:PASS sudo fio -filename=/dev/sda -rw=read -direct=1 -iodepth 1 -thread -ioengine=psync -bs=4k -numjobs=1 -runtime=10 -group_reporting -name=fio_read > fio_read.txt 2>&1 0 The IOPS number in fio_read test is: 1104 test_case_id:fio_read result:PASS measurement:1104 units:persecond <LAVA_SIGNAL_ENDRUN fio-ubuntu db652397-5831-4cc3-b2b3-1246879ac696> <LAVA_DISPATCHER>2014-05-13 12:30:39 PM WARNING: Invalid measurement <LAVA_DISPATCHER>2014-05-13 12:30:39 PM WARNING: Invalid measurement The regular expression I'm using is: "^test_case_id:(?P<test_case_id>fio_\\w+)\\sresult:(?P<result>(PASS|FAIL))\\s*(measurement:)*(?P<measurement>\\d*)\\s*(units:)*(?P<units>\\s*)\\s*" which if convert it to a solid one would be: "^test_case_id:fio_\w+\sresult:(PASS|FAIL)\s*(measurement:)*\d*\s*(units:)*\s*\s*" And it has been tested locally which can capture following 3 different results (sample): test_case_id:fio_read result:PASS measurement:1105 units:persecond test_case_id:fio_read result:PASS test_case_id:fio_read result:FAIL - Command ran failed on /dev/sda A local test script in Python is: #!/usr/bin/env python import re pattern_solid = "^test_case_id:fio_\w+\sresult:(PASS|FAIL)\s*(measurement:)*\d*\s*(units:)*\s*\s*" testcase_name = "fio_read" iops_result = "1105" test_string_pass = "test_case_id:" + testcase_name + " result:PASS " + "measurement:" + iops_result + " units:persecond" test_string_pass_simple = "test_case_id:" + testcase_name + " result:PASS" test_string_fail = "test_case_id:" + testcase_name + " result:FAIL" + " - Command ran failed on /dev/sda" print re.search(pattern_solid, test_string_pass) print re.search(pattern_solid, test_string_pass_simple) print re.search(pattern_solid, test_string_fail) So would you provide an example about how to deal with the measurement in LAVA? Thanks. Best Regards Botao Sun

11 years, 3 months

Week #19

by Arthur She

# Progress # * [QA-811] * Built and tested successfully by new manifest.xml with piglit / waffle / mesa3d in it. # Plan # * [CARD-489] * Sync with Milosz for next step * [BUG-1296880]

11 years, 3 months

Package update

by Neil Williams

lava-dispatcher | 2014.04.12.17-1 | sid | armhf, arm64, amd64, i386, source lava-server | 2014.04.12.18.08-1 | sid | armhf, arm64, amd64, i386, source lava-tool | 0.11.1-1 | sid | armhf, arm64, amd64, i386, source I haven't migrated these to jessie or built for ubuntu yet. This is an interim update for improvements to the remote worker setup along with documentation. The packaging follows standard policy that one package does not interfere with the configuration of another package, so there are manual steps required to configure some packages: postgresql - listen_addresses & trusted access for each worker fuse - enable user_allow_other ssh - copy the generated SSH key from the worker to the master lava-coordinator - point at the master coordinator These changes can be deployed using tools like salt and will be respected by subsequent package upgrades unless the relevant packages are purged. (Standard apt/dpkg behaviour: apt-get remove will leave the configuration files in place, apt-get --purge remove will remove those as well.) The update also includes a fix for lava-dispatcher LAVA_NETWORK_IFACE setup and the latest update of lava-tool. -- Neil Williams ============= http://www.linux.codehelp.co.uk/

11 years, 3 months

[Activity] Week #19

by Senthil Kumaran

# Progress # * Bug 1316688- lava-test-case attach no long works * vm-groups testing * pending cards prioritized and design planning * various code reviews * Time * Bug #1316688 - 30% * vm-group testing - 30% * various code reviews - 20% * card cleanup/prioritize/design - 20% # Plan # * pending LAVA cards * bug fixes -- Senthil Kumaran http://www.stylesen.org/ http://www.sasenthilkumaran.com/

11 years, 3 months

[Activity] Week #19

by Neil Williams

# Progress # * LAVA-333 * Fixed issue with Ubuntu builds * Migrated linaro-dashboard-bundle into lava-dispatcher & lava-server (inc. unit tests) * Migrated linaro-django-xmlrpc into lava-server (inc. unit tests) * Time * packaging : 100% # Plan # * remote worker testing & documenting for packaging branch * migration planning for merging packaging branch -- Neil Williams ============= http://www.linux.codehelp.co.uk/

11 years, 3 months

[Activity] Week #19

by Antonio Terceiro

# Progress * Investigated and designed a solution for supporting automatic network bridging on the host for vm group jobs. Draft code written. * Relesed lava-tool 0.11 (and 0.11.1) * Wrote patches for 2 important bugs related to vm groups: * lava multinode helpers missing from vmgroup jobs https://bugs.launchpad.net/lava-dispatcher/+bug/1317504 * not possible to submit vmgroup job from lava-tool https://bugs.launchpad.net/lava-tool/+bug/1317467 # Plan * Having those bug fixes landede and deployed to production * Tackle a couple of other high priority bug fixes that are pending * Implement support for manual signaling for starting the VMs of a VM groups job to support the use case of native building qemu as part of the host test definition. -- Antonio Terceiro Software Engineer - Linaro http://www.linaro.org

11 years, 3 months

lava-tool 0.11 released

by Antonio Terceiro

Hello, We have just released lava-tool version 0.11. This version adds a new --block option to the `lava-tool submit-job` command, that will make lava-tool block until the job finished running on LAVA. In the near future this feature will be expanded so you can watch the job run from your terminal. The sources are available on PyPi: https://pypi.python.org/pypi/lava-tool Binary packages for Ubuntu are available in the Linaro tools PPA: https://launchpad.net/~linaro-maintainers/+archive/tools/ -- Antonio Terceiro Software Engineer - Linaro http://www.linaro.org

11 years, 3 months

making LAVA aware of known-good images for each device type

by Antonio Terceiro

Today the LAVA team was discussing how we could make LAVA aware of known-good images for each device type. The use case is: when learning LAVA, engineers will often not know exactly which images to use, and they usually don't care much as they want first to learn how to use LAVA itself. To solve this problem, we came up with the following proposal. The LAVA admin should be able to configure the URL of a mini-database of know good images for each of its device types. The proposed format is a very simple YAML hash like this: ----------------8<----------------8<----------------8<----------------- kvm: action: deploy_linaro_image parameters: image: "http://url.to/kvm.img" kvm-arm: action: deploy_linaro_kernel parameters: kernel: "http://url.to/zImage" rootfs: "http://url.to/rootfs" dtb: "http://url.to/dtb" arndale: action: deploy_linaro_image parameters: image: "http://url.to/arndale.img" ----------------8<----------------8<----------------8<----------------- LAVA will just poll this database from time to time, but won't care how it is kept up to date. LAVA admins can make the generation of this database part of their automation. In Linaro, we should probably generate this data from releases.linaro.org. Fathi, can we generate this as part of the release process? If not, can we at least have a MANIFEST of the full contents of each release, so that we can generate that database on our side? Assuming the directory strutcure of releases is stable, the output of `find .` inside the release directory should be good enough. -- Antonio Terceiro Software Engineer - Linaro http://www.linaro.org

11 years, 3 months

Package updates - expanded support

by Neil Williams

lava-server | 2014.04.06.13.52-1 | sid | armhf, arm64, amd64, i386, source lava-server | 2014.04.06.13.52-1 | jessie | armhf, arm64, amd64, i386, source lava-server | 2014.04.08.12.04-1 | unicorn | amd64, source lava-server | 2014.04.08.12.04-1 | trusty | amd64, source lava-dispatcher | 2014.04.06.13-1 | sid | armhf, arm64, amd64, i386, source lava-dispatcher | 2014.04.06.13-1 | jessie | armhf, arm64, amd64, i386, source lava-dispatcher | 2014.04.08.10-1ubuntu1 | unicorn | amd64, source lava-dispatcher | 2014.04.08.10-1ubuntu1 | trusty | amd64, source There had been problems with the Ubuntu build of lava-server but those are now fixed and the Debian build uses the same Apache configuration. The helpers in the lava-dev package allow for local builds on Ubuntu and a few selectively copied packages mean that lava-server is now installable on Debian testing (Jessie) as well as unstable (sid). NOTE: The Ubuntu builds may not always be the absolute latest code until the release process is formalised but when Unicorn is updated the same source will be copied into Trusty. The builds are also only for 64bit x86 (amd64) currently as these are local developer builds. All repositories continue to use the emdebian-archive-keyring package for SecureApt. apt sources for Debian ====================== deb http://people.linaro.org/~neil.williams/lava sid main deb http://people.linaro.org/~neil.williams/lava jessie main Ubuntu ====== *Ensure the universe component is enabled for the base installation* deb http://people.linaro.org/~neil.williams/ubuntu unicorn main deb http://people.linaro.org/~neil.williams/ubuntu trusty main NOTE-2: It is strongly recommended *NOT* to migrate existing LAVA instances on Precise 12.04LTS to Trusty 14.04LTS at this time. There is more to do to ensure that the job log files are moved efficiently. lava-deployment-tool is *NOT* capable of installing a LAVA instance on Trusty and l-d-t is *not* capable of migrating a LAVA instance to django1.6 which is used in the packaging. The Ubuntu packages have only been lightly tested but the server does run. The trusty repository simply includes some dependency packages which have already been included into Utopic Unicorn through the auto-merge with Debian. (If someone wants to do backports of those to Trusty, feel free.) There will be no packaging support for Ubuntu releases older than Trusty 14.04LTS or Debian suites older than Jessie due to the need for django1.6. Other distributions =================== Patches welcome .... if anyone is already working on Fedora packaging or wants to work on Fedora support, just do so & let us know if there are problems. There is one remaining dependency which is due to be merged into lava-server - linaro-django-xmlrpc. Other changes in the packaging branch are mainly cherry-picked updates from master for lava-server and lava-dispatcher. -- Neil Williams ============= http://www.linux.codehelp.co.uk/

11 years, 3 months

test job attachments no longer listed after recent lava upgrade...

by Basil Eljuse

Hello All, This might be a bug to report. My test definition do have run: steps: - "wget http://ssg-sw.cambridge.arm.com/downloads/testsuites/buildoutput.tar.gz" - "tar -xvzf buildoutput.tar.gz" - "cd buildoutput" - "./executeFTS.sh purge" - "lava-test-run-attach buildoutput_withresults.tar.gz application/x-gzip2" Prior to the upgrade I used to see the following logs uploaded in the results bundle Test job attachments * testdef.yaml (text/plain) (696 bytes) download<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5191/download> view<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5191/view> * return_code (text/plain) (2 bytes) download<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5192/download> view<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5192/view> * stdout.log (text/plain) (30.6 KB) download<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5190/download> view<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5190/view> * run.sh (text/plain) (721 bytes) download<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5193/download> view<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5193/view> * buildoutput_withresults.tar.gz (application/x-gzip2) (6.9 MB) download<http://pdsw-lava.cambridge.arm.com/dashboard/attachment/5194/download> However after the recent upgrade we did there are no test job attachments at all listed, not just the buildoutput_withresults.tar.gz which I was specifically looking for. Test job attachments None Any clue? Should we be setting something explicitly now to allow attachments in the results bundle? Do note I am using the same testdefinition before and after upgrade! Thanks Basil Eljuse... -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

11 years, 3 months

← Newer
1
...
16
17
18
19
20
21
22
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation