Hi Lava Team,
Can anyone assist me with these 2 quires as
1. Can we enable interface inside LXC to access host network, so
that we can access any device on network of host machine and can access
internet inside LXC to execute script.
2. Can we pass Params in Lava job, which can propagate to
lava-test-action job or yaml.
If possible can you guide me with process to perform this
action ? share a reference job which perform this task.
--
Thanks & Regards
Chetan Sharma
Dear all,
Do you have any example or recommendation on the way to implement the following use case in Lava?
DUT under Linux
A PC under Linux to use as a "server" for VLC or iPerf test cases
I guess Multinode can be used to manage these use cases, but I don't know how to deal with the constraints linked to the PC: no reboot, no dedicated test kernel.
Thanks,
Denis
Hi Neil, Kevin !
> On 20 July 2017 at 02:57, Kevin Hilman <khilman at baylibre.com> wrote:
> > Hello,
> >
> > There are many configurable options when starting QEMU that are
> > controlled by environment variables, and I'm trying to figure out how to
> > pursuade LAVA v2 to set them.
>
> It's not something which should be done with the QEMU device type
> because that is installed on the worker - it is not a device that can
> be reconfigured to suit test writers and much of the functionality of
> QEMU must remain off-limits when QEMU is running on the worker.
>
> > As an example, configuring the host audio driver used by QEMU is set by
> > running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64.
>
> The worker is typically a server, it might not have any audio support.
> Even if it does, that functionality is off-limits to test writers. The
> available options to QEMU must be tightly constrained to protect other
> tasks on the worker.
A see. There is a valid point here in that there should not be control of the
environment from the 'outside' though a job description.
>
> > Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to
> > override the qemu-system binary used (it's conditional based on arch),
>
> This is deliberate, to protect the worker from aberrant processes and
> to give the admins sufficient control over how the worker behaves.
Now for the above case:
QEMU_AUDIO_DRV=<option> qemu-system-*
I see this as a *very valid env var* for a server-side deployment - exactly as
you said - a server does not have a sound card and QEMU_AUDIO_DRV=none is what
we need to use there to prevent qemu from looking for a host sound card. We
should even set this by default - we don't expect any sound to reach the
worker - do we ;) ? I don't think so.
IMHO this should be an option set on the worker node in the lava-
dispatcher.conf (e.g. LAVA_EXTRA_QEMU_ENV="QEMU_AUDIO_DRV=none").
Enable the admins to choose this.
>
> No. This is not something that the worker can support. It needs to
> happen only on a test device. The worker is not itself a test device.
As I said, I think this belongs to the worker setup and we should enable the
admins to make their choice.
Dipl.-Ing.
Jan-Simon Möller
jansimon.moeller(a)gmx.de
Hello,
There are many configurable options when starting QEMU that are
controlled by environment variables, and I'm trying to figure out how to
pursuade LAVA v2 to set them.
As an example, configuring the host audio driver used by QEMU is set by
running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64.
Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to
override the qemu-system binary used (it's conditional based on arch),
but even a quick hack to allow it to be overriden[1], and adding the env
as a prefix didn't because LAVA assumes the first item is an actual
binary expected in $PATH. My attempt led to:
Invalid job definition
Cannot find command 'QEMU_AUDIO_DRV=none qemu-system-x86_64' in $PATH
Seems like there should be a more general way to pass enviornment
variables to QEMU that I must be missing. If there's not, would be the
recommended way to add this feature?
Kevin
[1]
diff --git a/lava_scheduler_app/tests/device-types/qemu.jinja2 b/lava_scheduler_app/tests/device-types/qemu.jinja2
index 786f53bdb30d..e7c265a3048b 100644
--- a/lava_scheduler_app/tests/device-types/qemu.jinja2
+++ b/lava_scheduler_app/tests/device-types/qemu.jinja2
@@ -41,7 +41,7 @@ actions:
{% elif arch == 'arm' %}
qemu-system-arm
{% elif arch == 'amd64' or arch == 'x86_64' %}
- qemu-system-x86_64
+ {{ qemu_command|default('qemu-system-x86_64') }}
{% elif arch == 'i386' %}
qemu-system-i386
{% endif %}
With that change, I added
context:
qemu_command: "QEMU_AUDIO_DRV=none qemu-system-x86_64"
to the job definition
Dear lava Community,
I want to use Image charts2.0 for viewing my lava job results.
I am using "lava-test-case" to check pass/fail & I am getting results also.
steps:
- lava-test-case linux-linaro-ubuntu-pwd --shell pwd
- lava-test-case linux-linaro-ubuntu-uname --shell uname -a
- lava-test-case linux-linaro-ubuntu-vmstat --shell vmstat
I want to know how to get these results in image charts, I can see it ask to add chart & addfilter , but there no data is available when I try to add filter?
Similarly if I have to use query api, what kind of query should be used to fetch test data from lava suite?
Detailed info to use image chart will be appreciated, as I am new to Charts/Lava...or at any link.
Thanks,
Varun
Hi everyone,
I'm trying to add own device-type to my lab, but I'm facing some
difficulties when running jobs. I have the following log error:
https://pastebin.com/Eznq6RLA
I clearly understand the log but I'm not able to figure out what to do: I
thought it will be enough describing boot/power actions into device-type.
But it seems not... Do I need to create a .conf file into
/usr/lib/python2.7/dist-packages/lava_dispatcher/default-config/lava-dispatcher/device-types
folder ?
By the way I'm not sure to understand the .conf purpose ? Are they here,
only to be some default files ?
I attached my device-type and my job, maybe it will help you !
Thanks a lot ;)
P.S: I already did some jobs on Qemu and bbb and read the whole
documentation.
--
- Confidential -
Hi,
I'm not entirely sure this job definition is correct, but the only
error I'm getting is only "Problem with submitted job data: Invalid
YAML - check for consistent use of whitespace indents.". The YAML
validates just fine so I'm unsure what is wrong. Any hints? The YAML
in question is enclosed.
milosz
Hello,
We use a python script, LAVA_via_API, to trigger our test jobs.
I must say that I don't know whether this script is a pure internal creation or whether it's been inspired by a Linaro script.
Its role is simple, create a lava job with quite a few parameters (job name, server, worker, kernel, rootfs, dtb, device, device_type, and so on), submit the job, get results and logs.
Whatever, before reworking completely this script, I assume that a reference one exists on one of the Linaro gits. Can you tell me where to find this?
Thanks,
Denis
