Hi all,
Unfortunately I've woken up still running a temperature, so I'm staying home again. I'll be online, but I'm focussing on helping Bernard out with his Lava configuration.
Thanks
Dave
Sent from my Aldis Lamp
Hi,
This is chandru. I have just gone through the web page(
http://lava.readthedocs.org/en/latest/) for getting some info about the
LAVA framework. And got the following doubts, few of the questions may be
very basic please bare with me I am very new to LAVA
- Is it possible to use the LAVA for testing different OS like (QNX ,
custom OS)?
- What should I do to add support to new OS in LAVA ?
- Where can i find the information about the LAVA architecture?
- how may days it requires to move to LAVA for testing linux based platfrom?
- What is the effort to add a support of new OS.
- Is it possible to use perl/ruby to write a test cases ? (only python is
supported )
Regards,
Chandru
Zygmunt here's a patch to support a "managed" version for your
versiontools. I fear you are going to want it more integrated into your
current classes, but as I looked at it - it seemed it would required me
making more changes to the classes than I felt comfortable with (or have
time to make). Would you merge this, or should we just try and do
something like this some other day when we have more time to do it better?
-andy
Hi Michael,
For the kernel and gcc information, after board booted up, we can just run:
1. uname -a
2. gcc --version
Then grab a part of output string, that's it.
For the boot and serial test, if we don't think comprehensively, then we
can say if 1 and 2 can be executed successfully and we have got output
string from it, then boot and serial test can be considered passed.
Idea?
Thanks.
Best Regards
Botao Sun
On Mon, Jan 28, 2013 at 10:34 AM, Michael Hudson-Doyle <
michael.hudson(a)linaro.org> wrote:
> Andy Doan <andy.doan(a)linaro.org> writes:
>
> > + Michael - he's the expert on this.
> >
> > On 01/25/2013 01:02 AM, Botao Sun wrote:
> >> Hi Fathi & Andy,
> >>
> >> I'm wondering that can we show more information on our Linux Linaro
> >> ubuntu daily test dashboard? I'm looking at our weekly manual test on
> >> these images and find that some test cases can be covered by our
> >> existing daily test with some minor modifications. For example, TI Panda
> >> 4460 board:
> >>
> >> [1]
> >>
> http://validation.linaro.org/lava-server/dashboard/image-reports/linux-lina…
> >>
> >> For our weekly manual test:
> >>
> >> [2]
> >>
> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZ…
> >>
> >> We fill kernel and gcc version in spreadsheet, perhaps we can just show
> >> these information on link [1].
>
> If this information can be reported to lava some how (a test run
> attribute?) then I think it should be easy enough and a good feature to
> write some code to display it on the image report page.
>
> >> Also, if board can boot up successfully, then test case "boot" &
> >> "serial" can be considered passed, and we can just add 2 extra rows
> >> for these 2 test cases.
>
> This seems a bit harder. I have a little nagging thing in my brain
> about how boot testing is sort of implicitly tested / reported at the
> moment, which might be the better thing to fix...
>
> Cheers,
> mwh
>
Hello,
I'm offline Tue/Wed, so here's update on CBuild/LAVA (other folks from
Infra should be present on Tue hangout).
We've been doing integration testing since end of last week, and
generally it looks good. We didn't have complete end-to-end GCC build
due to PandaES + USB drive availability issues, but I tested gcc build
on Panda instead (this has some OOMs during "make check" in gcc), and
smaller builds like cortex-strings on PandaES.
So, everything looks good for deployment on Thurs, just 2 following
issues are on critical path:
1. Patches
(https://code.launchpad.net/~linaro-infrastructure/+activereviews)
review by TCWG. Matt, I guess you were busy with toolchain release
last week, but we'd appreciate your review now.
2. Merging the changes, assuming they're ok. Infra people don't have
commit access to CBuild repos, so we depend on TCWG here too. Actually,
it may be expected that after initial launch, we'll need to do more
changes and tweaks, so it may be good idea to give Infra (temporary)
commit access to streamline process. It would be nice to discuss this
during Tue hangout.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hello,
As far as I can tell, LAVA currently doesn't set hostname of a LAVA
board when running tests, which leads for usage of whatever generic (or
random) value was configured in build image. That may pose problem if
test/build uses hostname for some logging or identification.
For example, CBuild included hostname in build result id, based on which
various logs and result bundles are named, and which then gets parsed
by CBuild frontend to display build results. So, we got confusing and
inconsistent results from LAVA builds. I so far worked that around by
setting CBuild/LAVA builds' hostname to "lava", but that doesn't match
how native CBuild builds work, for example,
http://cbuild.validation.linaro.org/helpers/buildlog page shows
build matrix per individual board, based on hostname.
I tried to investigate how it happened that lava-dispatcher doesn't try
to set hostname, and actually found it used to, but that was tied to
recognition of test prompts, and once that was refactored, setting
hostname also gone, see
http://bazaar.launchpad.net/~linaro-validation/lava-dispatcher/trunk/revisi…
(grep for "_customize_ubuntu" - it got factored out to another file,
and lost /etc/hostname setting in progress).
So, please let me know if the above makes sense, and should be files as
lava-dispatcher bug, or are there other reasons for not setting a
hostname.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
All,
Woken up this morning feeling really unwell. Dizzy and breathless. If the feelings persist I'm going to see a doctor.
Will keep you informed.
Thanks
Dave
Sent from my Aldis Lamp
Hello,
(This mail could have epigraph "I'm starting to get CBuild" ;-) ).
I'd like to draw some attention to native CBuild builders. There appear
to be quite a backlog of builds ("Pending" section at
http://cbuild.validation.linaro.org/helpers/scheduler ), which appear
to be caused by builders problems.
On Friday night, I noticed that tcpanda05 was hanging for around a
week, and rebooted it, based on the information provided by Dave
previously. Hope that's ok, as it happily cutting size of a9-daily's
backlog since then (and sorry for letting know just now, again, it was
off usual working hours). a9-daily's queue does decrease, but rather
slowly. At the same time, that queue has tcpanda06 board commented out
- it went that way with initial import "scheduler" repo, so I couldn't
know exact reason. Generic one is understood - so tcpanda06 could
quickly pick up jobs from other queues, but that means it spends idle
half a day. So, I temporarily re-enabled it for a9-daily to process
backlog, that change is clearly commented and easily bzr diff'able on
toolchain64.
That ends list of issues I actively poked at, but there're more I
couldn't:
1. tcserver01x5, which belongs to x86_64-heavy queue, and apparently is
a VM hosted in lava lab, hangs for 16 days, with a dozen jobs in
backlog. "tcserver01x5" didn't ping for me from gateway, but
"tcserver01" does, so maybe it's live but has some issues.
2. a9hf-daily has single active machine, tcpanda11, so that's in
permanent, and probably growing, backlog.
I understand that leveraging LAVA builds is probably the best way to
resolve the issue, and I'm currently validating and tweaking those
builds (but I'm not sure if build image as was provided by Michael is
hardfloat or not, and how to go about adding missing one).
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi Michael,
In the last 2 days I'm trying to write some test case definition files but
I'm confused about the format. I have made some experiments and here is my
observation:
I use Panda ES as an example, and the YAML file looks like this:
metadata:
format: Lava-Test Test Definition 1.0
name: botao-panda-es-ubuntu-test
run:
steps:
- lava-test-case botao-panda-es-ubuntu-test-uname --shell echo
"This is a test" || true
- lava-test-case botao-panda-es-ubuntu-test-uname --shell uname -a
true
- lava-test-case botao-panda-es-ubuntu-test-uname --shell "ifconfig
-a" || true
Then the second line will be failed to run by an index error:
- lava-test-case botao-panda-es-ubuntu-test-uname --shell uname -a true
The first and the third line can be executed successfully. The "|| true"
will let the command line to return a "true" value whatever its status. But
on the LAVA wikipage it says:
The second form is indicated by the –shell argument, for example:
run:
steps:
- "lava-test-case fail-test --shell false"
- "lava-test-case pass-test --shell true"
Then if I write like the example shows, it will fail to run. So do we need
to update that wiki example or is there something wrong in my understanding?
Thanks.
Best Regards
Botao Sun
Looks like we need to plan for some downtime while this happens. I'll make sure I take the boards offline. Can we run something outside the lab to keep availability of job submission?
Thanks
Dave
Begin forwarded message:
> From: "Lee Heyes" <central.monitoring(a)zen.co.uk>
> Subject: Notification of Planned Maintenance [5468619:4172292]
> Date: 26 January 2013 05:23:06 GMT
> To: <dave.pigott(a)linaro.org>
>
> Dear Leased Circuit Customer,
>
> We have been notified of planned maintenance affecting your leased line service, the details of which are included below.
>
> Affected installation address:
> Suite 220
> The Quorum
> Cambridge
> Associated Order ID: 803244
>
> Maintenance window start: 06/02/2013 - 23:55
> Maintenance window end:07/02/2013 - 06:00
>
> Impact: Loss of connectivity on leased circuit
> Expected impact duration: Up to 30 minutes
>
> Reason given for maintenance: Essential switch Maintenance in London PoP
>
> Your service will be at risk of additional or extended outages for the duration of the maintenance window.
>
> If you have any queries regarding this maintenance, please contact our Central Monitoring Team using the details below.
>
> Information relating to this outage including any updates will be posted on our Service Alerts page http://status.zensupport.co.uk/active/3/2880
>
> We apologise for any inconvenience this may cause.
>
> Kind Regards,
>
> Central Monitoring Team
> --
> Zen Central Monitoring
> E: central.monitoring(a)zen.co.uk
> T: 0845 058 9010
> F: 0845 058 9001
> W: www.zensupport.co.uk
>
> Service Alerts: http://status.zensupport.co.uk/
>
> ------------------
> Fibre Offer – Free installation on Fibre Optic Broadband orders placed before 31st March 2013, subject to a 24 month contract. http://www.zen.co.uk/home-office/broadband/fibre-optic-broadband.aspx
>
> Please consider your environmental responsibility before printing this email.
>
> This message is private and confidential. If you have received this message in error please notify us and remove it from your system.
>
> Zen Internet Limited may monitor email traffic data to manage billing, to handle customer enquiries and for the prevention and detection of fraud. We may also monitor the content of emails sent to and/or from Zen Internet Limited for the purposes of security, staff training and to monitor quality of service.
>
> Zen Internet Limited is registered in England and Wales
> Sandbrook Park, Sandbrook Way, Rochdale OL11 1RY
> Company No. 03101568
> VAT Reg No. 686 0495 01
