Dear all,
I'm testing QEMU on LAVA with my first job.
I have taken a sample here:
https://staging.validation.linaro.org/static/docs/v2/first-job.html#index-0
But, it's failed at "apply-overlay-guest" action:
Overlay: /var/lib/lava/dispatcher/slave/tmp/15/overlay-1.3.4.tar.gz
Traceback (most recent call last):
File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line
290, in run_actions
new_connection = action.run(connection, args)
File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/deploy/apply_overlay.py",
line 83, in run
self.job.device['actions']['deploy']['methods']['image']['parameters']['guest']['size'])
File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/utils/filesystem.py",
line 128, in prepare_guestfs
guest.launch()
File "/usr/lib/python2.7/dist-packages/guestfs.py", line 5705, in launch
r = libguestfsmod.launch(self._o)
RuntimeError: /usr/bin/supermin exited with error status 1.
To see full error messages you may need to enable debugging.
Do:
export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again. For further information, read:
http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
I'm using docker LAVA version 2017.11. And, attached is my log.
Do you have idea for this issue?. Thanks in advance
Best regards,
Canh Nguyen
My contact email:
phongcanhit(a)gmail.com
canh.nguyen.vz(a)rvc.renesas.com
Hi,
I am using Lava as our automation test infrastructure now. Now we are trying find all key words collection in Jobs.
For example:
timeouts:
job:
minutes: 30
action:
minutes: 30
priority: medium
visibility: public
actions:
- deploy:
timeout:
minutes: 30
to: docker
os: debian
packages: [python]
key word to and os, its value is docker and debian here. Maybe there are different value for these ker words in another jobs. We just want to find all these possible value for these key word in Lava.
Could anyone kindly provide some method and configuration file/document to find this efficiently? Thanks in advance.
Thanks,
Deli
Hello everybody,
I have some testcases which need a remote network connection to the DUT. I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT.
Implementation:
* DUT and LXC are deployed and booted as two roles in a multinode job
* DUT sends its IP address to LXC via the multinode API (lava-send) and then waits for a signal (lava-wait)
* LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
* DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
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
Hello Lava-Users,
When we want to use SSH as the primary remote connection for connecting to
target and executing tests in LAVA how should private key which can be used
for this connections be placed.
Is there any sample job definition example for this type of connection.
Thanks,
Hemanth.
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
Hello
I want to introduce a devicedict parameter for differentiate
mainline/vendor uboot.
For example, amlogic boards could work with both, but thet have some
differences like uboot prompt.
So for example I have modified
lava_scheduler_app/tests/device-types/meson-gxl-s905x-khadas-vim.jinja2
like this:
+{% if use_vendor_uboot %}
{% set bootloader_prompt = bootloader_prompt|default('kvim#') %}
+{% endif %}
Note that my way is to assume that mainline uboot is the default.
But since non-amlogic boards (imx6q-sabrelite for example) will need the
same way for differentiate, having an agreement on the name could be
usefull.
Does use_vendor_uboot is good for you ?
Regards
On 26 April 2018 at 10:26, Conrad Djedjebi <conrad.djedjebi(a)linaro.org>
wrote:
> Good morning everyone,
>
Changing to the lava-users mailing list.
>
> I am looking for some advice with the LAVA Scheduler App.
> I noticed the file /etc/lava-server/settings.conf is not allowing users to
> activate debug messages from the LAVA Scheduler App.
>
settings.conf is for Django settings (which includes support for DEBUG =
True) and that can be enabled on any development instance.
There is also the django-toolbar which can be used for UI work.
https://staging.validation.linaro.org/static/docs/v2/debian.html#debugging-…
>
> Is there a way to activate debug messages in LAVA Scheduler App? If it is
> the case, which file shall I edit?
>
> In the file /lava_scheduler_app/models.py for instance, some loggers are
> being called. However, their outputs are not appearing during the job
> process.
>
logging goes into the lava-master logs typically.
Django exceptions go into the django.log
There is more on this in the documentation.
https://staging.validation.linaro.org/static/docs/v2/development.html#devel…https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html#de…
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi all,
I've encountered a deadlock in my LAVA server with the following scheme.
I have an at91rm9200ek in my lab that got submitted a lot of multi-node
jobs requesting an other "board" (a laptop of type dummy-ssh).
All of my other boards in the lab have received the same multi-node jobs
requesting the same and only laptop.
I had to take the at91rm9200ek out of the lab because it was behaving.
However, LAVA is still scheduling multi-node jobs on the laptop which
requires the at91rm9200ek as the other part of the job, while its status
is clearly Maintenance.
Now, until I put the at91rm9200ek back in the lab, all my boards are
reserved and scheduling for a multi-node job and thus, my lab is
basically dead.
Let me know if I can be of any help debugging this thing or testing a
possible fix. I'd have a look at the scheduler but you, obviously
knowing the code base way better than I do, might have a quick patch on
hand.
Best regards,
Quentin
Hi everyone,
I am writing this email in order to have your opinion on the following :
I am trying to use LAVA Notifications in my LAVA instance. I used the
following template in one of my LAVA Test Job Definition files :
notify:
recipients:
- to:
method: email
email: conrad.djedjebi(a)linaro.org
criteria:
status: complete
verbosity: verbose
compare:
query:
name: OPTEE_xtest_Jobs
username: admin
In that template, OPTEE_xtest_Jobs is the name of a query (testjob query)
and admin is the user who owns that query. The query is listing all the
completed jobs of that kind (I mean that the job I am currently running
will be listed in the query OPTEE_xtest_Jobs).
But each time my LAVA job is completed, I am not getting any email
notification.
In my user profil (my user name is conrad in the instance of LAVA I am
working on), I already provided an email. So even if I used the following
template, I should have get an email notification :
notify:
recipients:
- to:
method: email
user: conrad
criteria:
status: complete
verbosity: verbose
compare:
query:
name: OPTEE_xtest_Jobs
username: admin
Is there a point I missed? If anyone has some advices to give me in order
to get the notifications work, I would appreciate.
regards,
> lava-server and lava-dispatcher have been merged into a single source repository - lava
If you ask me, this is the (very) questionable decision. Indeed!?
lava-server is the front-end manager of the whole Lava test
environment, while lava-dispatcher is the back-end. Connected/splitted
by ZMQ protocol. And... They should be separately maintained, since
they represent (very) different things. Essentially, they do (very)
different tasks. They are, after all, apples and oranges.
In other words, if you update/buy advanced/more expensive apples, you
also force testers to update for nuthin'/buy for the loss the same
oranges, they had before?!
Is it the wise decision???
Two cents worth lamenting/analysis,
Zoran
_______
On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams <neil.williams(a)linaro.org> wrote:
> This is for particular note for developers as it changes the way that
> reviews happen.
>
> If you've noticed a few reviews being abandoned, this is why.
>
> lava-server and lava-dispatcher have been merged into a single source
> repository - lava
>
> lava-coordinator will follow in time, to ease the update of lava-coordinator
> to Python3.
>
> This will, in future, allow easier testing of device integrations by
> allowing the lava_scheduler_app unit tests to be linked to the
> lava_dispatcher unit tests and have a single review which adds both sides of
> the device support.
>
> There will be a lot of testing, as normal, so staging will be moving to
> packages built from the new source repository tree.
>
> The old lava-server.git and lava-dispatcher,git repositories will become
> read-only and will get no further code changes. All changes will be done in
> lava.git
>
> https://git.linaro.org/lava/lava.git/
>
> The documentation will be updated over the next few days.
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
>
> _______________________________________________
> Lava-announce mailing list
> Lava-announce(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-announce
>
