Hi,
I'm trying to submit job for TC2 now and I'm in the long queue. There
seem to be a few multinode Android jobs that run on dummy-ssh and
vexpress-tc2 (workload automation). We only have one dummy-ssh device
so there is no way that more than one TC2 is going to be used with
dummy-ssh at the same time. On top of that we have
vexpress-tc2-benchmark which also can run multinode jobs with
dummy-ssh. For some reason if there are couple of multinode jobs
requested for dummy-ssh + vexpress-tc2, the TC2 boards get reserved
and there is no way to submit any other jobs there. While I understand
that 1 board might be in reserved state, there is no point to reserve
all 3 (there is only one dummy-ssh). IMHO this is a bug in multinode.
Current status is:
dummy-ssh: 7 jobs in the queue
vexpress-tc2: 3 reserved + 3 jobs in the queue
I know that proper solution should be moving with WA to dynamically
allocated VMs, but unfortunately licensing is in the way.
milosz
# Progress #
* [QA-811]
* Submitted the patch and it had been merged
http://review.android.git.linaro.org/#/c/11034/
*[QA-714]
* Tested fwts with laptop and found options which can make log easy to
parse
# Plan #
* [QA-714]
* [BUG-1296880]
# Progress
* Landed fixes for
* #1303900: timeout when trying to filter on big number of test results
* #1317467: not possible to submit vmgroup job from lava-tool
* #1317504: lava multinode helpers missing from vmgroup jobs
* Achieved an advanced stage on the implementation of support for manual start
of virtual machines in vm group jobs (LAVA-1309)
Time:
* 60% the above high priority bugs
* 40% LAVA-1309
# Plan
* LAVA-1297: Allow Multiple lava-test-shell test executions on a single target
* LAVA-1304: spawn hacking sessions from lava-tool
--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org
# Progress #
* LAVA-333
* Documented the migration procedure to Ubuntu Trusty and Debian Jessie
- based on repeated migration tests in VMs.
* Began the migration of playground (issue with Trusty kernel & xenserver
- ported to a kvm base by Matt
* Time
* packaging : 30%
* migration: 70$
# Plan #
* complete migration of playground & run test jobs
* migrate staging and run the functional tests
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Hi Alan,
I'm afraid you missed the mailing list. :)
Finally I have managed to show the measurement in LAVA, though the unit is
still missing:
https://validation.linaro.org/dashboard/streams/anonymous/botao-sun/bundles…https://validation.linaro.org/dashboard/attachment/791281/view
I tested the regular expression on a website and locally, it works well on
both, for example:
1. Tested on a third-party website:
https://pythex.org/?regex=
^%28%3FP%3Ctest_case_id%3Efio_\w%2B%29%3A\s%28%3FP%3Cresult%3E\w%2B%29\s%28%3FP%3Cmeasurement%3E[0-9.]%2B%29\s%28%3FP%3Cunits%3E\w%2B%29.*&test_string=fio_read%3A%20PASS%201105%20IOPS%0Afio_read%3A%20PASS%200%20NA%0Afio_read%3A%20FAIL%200%20NA%20-%20Command%20ran%20failed%20on%20%2Fdev%2Fsda&ignorecase=0&multiline=1&dotall=0&verbose=0
2. Tested locally:
#!/usr/bin/env python
import re
test_string_pass = testcase_name + ": PASS" + " " + iops_result + " " +
"IOPS"
print test_string_pass
test_string_pass_simple = testcase_name + ": PASS" + " 0" + " NA"
print test_string_pass_simple
test_string_fail = testcase_name + ": FAIL" + " 0" + " NA" + " - Command
ran failed on /dev/sda"
print test_string_fail
pattern =
'^(?P<test_case_id>fio_\w+):\s(?P<result>\w+)\s(?P<measurement>[0-9.]+)\s(?P<units>\w+).*'
print re.findall(pattern, test_string_pass)
print re.findall(pattern, test_string_pass_simple)
print re.findall(pattern, test_string_fail)
The output is:
fio_read: PASS 1105 IOPS
fio_read: PASS 0 NA
fio_read: FAIL 0 NA - Command ran failed on /dev/sda
[('fio_read', 'PASS', '1105', 'IOPS')]
[('fio_read', 'PASS', '0', 'NA')]
[('fio_read', 'FAIL', '0', 'NA')]
As you can see all four groups are captured there.
Any idea?
Thanks.
Best Regards
Botao Sun
On 14 May 2014 04:57, Alan Bennett <alan.bennett(a)linaro.org> wrote:
> Hi Botao;
>
> I've had the most luck using the lava test shell api "lava-test-case",
> have you tried it?
>
> Senthil/LAVA team, do we have some examples of using parsers and
> measurements?
>
> Alan
>
> lava-test-case test5 --result pass --measurement 99 --units bottles
>
> Documentation:
>
> https://validation.linaro.org/static/docs/writing-tests.html?recording-test…
>
>
> ---------- Forwarded message ----------
> From: Botao Sun <botao.sun(a)linaro.org>
> Date: 13 May 2014 06:52
> Subject: [Linaro-validation] Measurement in LAVA.
> To: Linaro Validation <linaro-validation(a)lists.linaro.org>
>
>
> 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
>
> _______________________________________________
> linaro-validation mailing list
> linaro-validation(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-validation
>
>
>
>
> --
>
> Alan Bennett, Engineering Manager, LAVA & LSK
> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
> | Follow Linaro*:* Facebook <http://www.facebook.com/pages/Linaro> |
> Twitter <http://twitter.com/#%21/linaroorg> | Blog<http://www.linaro.org/linaro-blog/>
> irc: akbennett | alan.bennett(a)linaro.org |
> linaro-validation(a)lists.linaro.org
>
>
lava-server | 2014.04.13.15.23-1 | sid | armhf, arm64, amd64, i386, source
lava-dispatcher | 2014.04.13.14-1 | sid | armhf, arm64, amd64, i386, source
This update should complete the remote worker changes - note that the
majority of the changes in this update are in the documentation on how
to make, check and secure the manual steps in remote worker
configuration. There are some critical changes in the packages:
lava-dispatcher: the fuse and loop modules are *not* modprobed by
default. In most cases, these modules will be loaded automatically and
loading them again can cause noticeable problems. If a worker or master
does not show the fuse module being loaded at boot time, it can be
worth investigating whether a simple modprobe is sufficient. If the
module already exists or if a simple modprobe does not work, do *not*
uncomment the modprobe line in the /etc/modprobe.d/lava-modules.conf
file.
lava-server: the sshfs mountpoint only has sub-directories created on
the master and does not try to change permissions on files across the
sshfs from the worker side.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
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
# 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]
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/
