2014.04.23.14.01-1 is now available for jessie and sid,
2014.04.23.14.08-1ubuntu1 for trusty and unicorn.
This update addresses the OpenID support. Launchpad had an issue
previously because the CACert certificates were removed from the
ca-certificates package. Launchpad has since migrated to a certificate
which is supported by current (and old) ca-certificates packages.
The packaging branch migrated to Google+ OpenID during development but
that would not be an easy migration for the group support in LAVA.
Support for OAuth2 is being investigated.
This update re-instates Launchpad as the default OpenID server for the
packaging branch and includes documentation for how to stay with
Google+.
http://playground.validation.linaro.org/static/docs/installation.html#using…
"OPENID_SSO_SERVER_URL": "https://www.google.com/accounts/o8/id",
This change will be respected by future lava-server upgrades, so the
choice of OpenID service is open to the local admin.
(If there are other OpenID servers people want to use, this support
should work but note that OAuth2 is the preferred option, so it may
only be a temporary step.)
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
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/
