Hi all!
I am working on writing LAVA test definitions and using the callback method
to send test results to kernelCI.
I noticed a sort of bug (?) when the test definitions are reporting a lot
of elements. The job finishes and the callback gets triggered before the
end of the log parsing. I think the callback method is not waiting for the
parser to finish before sending the event. The callback output is then
missing some test results.
I made a simple test script that reports 300 test elements and returns. I
can see in the LAVA log that they are all detected. But in the callback
object there is around 80 test results.
If I add a sleep (15 seconds) to hold the script before returning, the
callback has the 300 test results bundled in the json.
Did anyone experienced this before ?
Thanks !
--
Loys OLLIVIER
Baylibre
I am currently evaluating if LAVA is the right tool for testing our custom flavour of a Raspbian Linux distro. The DUT is going to be a Raspberry Pi3 and I was trying to set it up in a minimal way using another Raspbi3 as a Server & Dispatcher (although first it seemed to work fine, when I followed the LAVA documentation and added the stretch backports sources in the apt list, my whole system crashed because of the depedencies).
What is the best way to get a minimal setup running? I am also interested to know the hardware process (ideally everything we want to be automated). So, should the DUT be connected via a USB2serial cable?
https://goo.gl/D5ZwxU
Other than that should that be connected to an SD multiplexer that burns the resulting .img after Jenkins finishes checking and generating it?
Documentation is a bit tricky to go through as it covers many cases and there's not a simpler minimal tutorial. Also all the online blogs/posts seem to work for LAVA V1 only as a few things have changed.
So it will look something like this:
Linux .img (to be tested) -> SD Multiplexer(?) - DUT - USB2Serial -> LAVA Server & Dispatcher
|
LCD Screen
Are there anywhere some sample tests so I can get an idea of what I will be able to do? (Had already a look at the linaro .git but those seem 'too' basic; probably I've missed smth).
Thank you all for your help.
Thanks again, Neil.
>Future proofing means keeping up with upstream and, hopefully, contributing
>the support back to upstream. A new Strategy class is a requirement for
>inclusion upstream, to be able to isolate this bootloader from future
>changes to better support U-Boot in ways that your bootloader cannot manage.
I get your point and agree with you on that. So does this mean you would accept contributions for a new bootloader, even if it is a proprietary one?
However, for a quick check how LAVA works I was able to go the hacky way and abuse the uboot class to send commands to our own bootloader. This led me to further questions:
1. The TFTP deployment strategy does not seem to support deploying a rootfs. Is that correct? If yes, why?
2. Our bootloader supports download via HTTP as well, so actually we could get the files from the web to the device directly. The test system would not need to download any files then. LAVA does not seem to support such a scenario. All deployment strategies download the files first, before performing further steps.
How could I handle this case in LAVA? Obviously I could remove the deploy action from the job completely and handle everything in the boot command sequence. Still I would need some possibility to specify the URL of the image within the job, which the boot command sequence then should use. Is there a way to achieve this? I assume the correct way would be to implement a new deployment strategy for this, which does not do anything. However, this seems a bit weird to me. Is there another way? Or would the whole idea work against the general LAVA workflow?
3. As far as I understand, LAVA needs to apply an overlay tarball to the image before executing tests, which is usually performed directly on the image file before it is deployed to the target. This would not work in the case of (2). But I saw there is a boot action "transfer_overlay" to do this after the actual deployment. Is it correct, that I could use this action in such a case?
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
Hey,
Not sure where to report LAVA bugs, https://wiki.linaro.org/LAVA (https://wiki.linaro.org/LAVA) indicates I should use the Linaro bugzilla but it seems to be closed? Anyway, I think there's an issue with the CSV result export in LAVA 2018.2, can anyone confirm?
Example CSV: https://validation.linaro.org/results/1686046/csv (https://validation.linaro.org/results/1686046/csv)
The first line of the CSV file is:
[u'job', u'suite', u'result', u'measurement', u'unit', u'duration', u'timeout', u'logged', u'level', u'metadata', u'url', u'name', u'id']1686046,12_bootchart-stop,pass,None,,,,2018-02-28 05:01:35.935783+00:00,,"{'case': 'generate-bootchart-graphic', 'definition': '12_bootchart-stop', 'result': 'pass'}",/results/testcase/2871860,generate-bootchart-graphic,2871860
.. when it probably should've been two lines:
job,suite,result,measurement,unit,duration,timeout,logged,level,metadata,url,name,id
1686046,12_bootchart-stop,pass,None,,,,2018-02-28 05:01:35.935783+00:00,,"{'case': 'generate-bootchart-graphic', 'definition': '12_bootchart-stop', 'result': 'pass'}",/results/testcase/2871860,generate-bootchart-graphic,2871860
I believe the issue is 1) a missing linebreak after the header-line and 2) the formatting of the header line (drop the Python repr stuff).
I have the same problem trying to login to admin on localhost. For me it's
independent of browser and browser cookie configuration. I assume it's an
issue with Django configuration.
Regards
Bill
--
EMEA Field Engineering
Linaro Ltd
Harston Mill CB22 7GG
Cambridge UK
+44 7833 498336 <+44%207833%20498336>
Good morning everyone,
I would like to show you the following :
Did anyone encounter that error in the past while trying to log into a
local standalone master instance of lava ?
I installed LAVA 2018 and the localhost page in being opened without
issues. Things get worst when I try to login.
I am getting that error on chromium and Firefox. Both of them have cookies
enabled.
Best regards,
Good morning everyone,
I am getting in touch with you in order to show you an issue i am facing
after submitting a basic Test Job Definition through my LAVA web page
(localhost). I am a new LAVA user.
After submitting my job, I see the following error in the job's page :
Something seems to be going wrong with "commands" and I am trying to figure
out what it is.
Did anyone already encountered this error in the past?
(I edited a jinja2 device type file and a jinja2 dictionary file as well to
match my device's properties. The device type file is saved in
/etc/lava-server/dispatcher-config/device-types/ and the device dictionary
file is saved in /etc/lava-server/dispatcher-config/devices/).
Thank you for your help,
Hi,
I have an impression that we can have test image "dummy" deployed once I am
sure the image in the device is bootable.
That will save time for downloading and flashing to the device.
Does it still be supported in LAVA v2?
Thanks,
Arthur
Hermanth,
You were able to install on stretch?
I was attempting to do so, but the python3-django-auth-ldap package
wasn't available on anything but sid.
Did you run into the same issue?
Regards,
Chris
> Date: Tue, 27 Feb 2018 14:10:46 +0530
> From: Hemanth K V <kv.hemanth.mys(a)gmail.com>
> To: Lava Users Mailman list <lava-users(a)lists.linaro.org>
> Subject: [Lava-users] set up issue
> Message-ID:
> <CAEua01SDZE6=7+rgnr6+1WA-j3Z3g2ECywP0qtT0xR8Z9GE9Gw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Lava-Users,
>
> After following the setup of LAVA on Debian 9 stretch and when we try to
> login from UI we face the following error Ref
> https://validation.linaro.org/static/docs/v2/installing_on_debian.html
>
> $ sudo apt install postgresql
> $ sudo apt install lava-server
>
> If the default Apache configuration from LAVA is suitable, you can enable
> it immediately:
>
> $ sudo a2dissite 000-default
> $ sudo a2enmod proxy
> $ sudo a2enmod proxy_http
> $ sudo a2ensite lava-server.conf
> $ sudo service apache2 restart
>
> Forbidden (403)
>
> CSRF verification failed. Request aborted.
>
> You are seeing this message because this site requires a CSRF cookie when
> submitting forms. This cookie is required for security reasons, to ensure
> that your browser is not being hijacked by third parties.
>
> If you have configured your browser to disable cookies, please re-enable
> them, at least for this site, or for 'same-origin' requests.
>
>
> Is there anything missing from the setup.
>
>
> Thanks,
>
> Hemanth.
Hi all,
Why I can't receive the email when I use the 'User notifications' in LAVA ?
notify:
criteria:
status: canceled
verbosity: quiet
recipients:
- to:
method: email
email: hongyu.xu(a)hxt-semitech.com<mailto:hongyu.xu@hxt-semitech.com>
or
notify:
criteria:
status: complete
verbosity: quiet
recipients:
- to:
user: '1680141'
method: email
[cid:image001.png@01D3AFE4.37D7A500]
Best Regards
XuHongyu
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.