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
ALWAYS keep the list in CC please.
On 7 July 2017 at 10:28, Chetan Sharma <chetan.sharma(a)timesys.com> wrote:
> Hi Neil
> Thanks for sharing detailed information to work with LXC.
> 1. I am following sample pipeline job with BBB.
> https://git.linaro.org/lava/lava-dispatcher.git/tree/lava_dispatcher/pipeli…
>
> I have modified this job details with following value, but i am getting an
> Error as ['Invalid job - missing protocol']
Check with the valid job:
https://staging.validation.linaro.org/scheduler/job/178130
> As i have defined protocol as "lava-lxc" which is valid protocol, But job
> object does not have any protocol details, i have verified by printing
> details of self.job.protocols is []
Then that is an invalid job. Your modifications have got something
wrong. There are a lot of changes in your file against the example.
Change only one thing at a time.
> 2. How test action execute on lxc and device ?
Run a test action in the same namespace as the LXC. In the case of the
example, namespace: probe.
https://staging.validation.linaro.org/scheduler/job/178130/definition#defli…
> Can we execute test action in this process
> First lxc test action execute ---> Device1 test action execution start
> -> Device2 test action execution start
>
>
> ==================================================
> device_type: beaglebone-black
>
> job_name: LXC and bbb
Please attach files to emails to the list. There's no need to quote
the entire file to the list.
Take time to understand namespaces. The LXC is transparent and the
namespaces are used to tie the different actions together into one
sequence in the LXC and one sequence for the test device.
LXC protocol support is not the same as MultiNode - operations happen
in series. The LXC protocol is not a substitute for MultiNode either.
If you need parallel execution, you have to use MultiNode.
Split up your test shell definitions if necessary.
Also, attach (not include) the full test job log because that contains
details of the package versions being used and other information.
> On Fri, Jul 7, 2017 at 1:32 PM, Neil Williams <neil.williams(a)linaro.org>
> wrote:
>>
>> On 7 July 2017 at 07:23, Chetan Sharma <chetan.sharma(a)timesys.com> wrote:
>> > Hi Everyone
>> > Hopefully everyone is doing well in this group.
>> > Main intend of writing this email to seek assistance in regard to
>> > one
>> > feature of Lava as lava-lxc which help to create a LXC instance on
>> > worker
>>
>>
>> https://staging.validation.linaro.org/scheduler/job/174215/definition#defli…
>>
>> > and then we can execute any script on worker and propagate its
>> > characteristics and result in another actions of Job on board.
>>
>> That isn't entirely clear. What are you trying to do in the LXC?
>>
>> You need to deploy an LXC, start it with a boot action for the LXC and
>> then start a test shell in the LXC where you can install the tools you
>> need to execute.
>>
>> Talking to the device from the LXC can be difficult depending on how
>> the device is configured. To use networking, you would have to have a
>> fixed IP for the device. To use USB, you need to use the device_info
>> support in the device dictionary to add the USB device to the LXC.
>>
>> > I have gone through documentation shared on Lava V2 instance for
>> > LXC
>> > job creation, but i am not able to successfully execute job on Debian
>> > Jessie
>> > Release.
>> >
>> > https://validation.linaro.org/static/docs/v2/deploy-lxc.html#index-0
>> >
>> > Can you assist me and share a reference process/document to proceed
>> > further to create a job using this feature.
>>
>> More information is needed on exactly what you are trying to do, how
>> the LXC is to connect to the device and what support the device offers
>> to allow for those operations.
>>
>> --
>>
>> Neil Williams
>> =============
>> neil.williams(a)linaro.org
>> http://www.linux.codehelp.co.uk/
>
>
>
>
> --
> Thanks & Regards
> Chetan Sharma
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi Everyone
Hopefully everyone is doing well in this group.
Main intend of writing this email to seek assistance in regard to one
feature of Lava as lava-lxc which help to create a LXC instance on worker
and then we can execute any script on worker and propagate its
characteristics and result in another actions of Job on board.
I have gone through documentation shared on Lava V2 instance for LXC
job creation, but i am not able to successfully execute job on Debian
Jessie Release.
https://validation.linaro.org/static/docs/v2/deploy-lxc.html#index-0
Can you assist me and share a reference process/document to proceed
further to create a job using this feature.
Look forward to hear with positive response.
--
Thanks & Regards
Chetan Sharma
