Hello Lava Users,
Is there any sample example describing the "Enabling Secondary Media".
I want to boot x86 based board with primary OS booted from USB and want to
deploy the image to SATA used as secondary media.
Thanks,
Hemanth.
Good morning everyone,
I am getting in touch with you in order to show you an issue i am
encountering while submitting a basic Test Definition through my LAVA web
page (localhost). I am a new LAVA user.
Both the two attached scripts are returning the following error in the
interface :
I checked the syntax of my yaml files using an online tool.
Here is a description of the steps I followed while installing the
Standalone Master instance of LAVA on my computer :
- Installing lava-server
- Setting up Apache2 server
- Setting ser2net
- Adding a superuser to lava system
- Creating a device type (.jinja2) file and a device
- Writing a Test Definition (.yaml file)
- Submitting that Test Definition through the GUI of lava
thank you for your help,
Hello all,
I am following steps mentioned in
https://validation.linaro.org/static/docs/v2/pipeline-server.html#zmq-curve
for installing lava dispatcher on local machine (slave which is my worker
machine) and
https://validation.linaro.org/static/docs/v2/installing_on_debian.html for
installing lava server on another machine (master)
I have added device through GUI using
https://validation.linaro.org/static/docs/v2/first-devices.html#create-devi…
documentation
I have successfully added worker to serevr side and able to get message
showing that encryption has been enabled on the both master and slave side.
I am able to run test job on added target which has worker as slave machine
on which my dispatcher is running.
My job is started it is showing runnig state but I am not getting any
console log in job summary.
please help me to get debug log in job summary.
Regards,
Mayuri.
More about proxies:
Here is update on the Lava proxy business. Please, read this very
carefully, since this is the solution to the problems with Lava
proxies, as well as Lava DUT ones.
YES, after applying what Remi advised to me, the qemu01 test:
https://www.validation.linaro.org/static/docs/v2/first-job.html
worked like a charm. I simply copied /etc/lava-server/env.yaml to
/etc/lava-server/env.dut.yaml (and created the new file).
Remi, I would like to thank you for the advise!
Best Regards,
Zoran Stojsavljevic
---------- Forwarded message ----------
From: Remi Duraffort <remi.duraffort(a)linaro.org>
Date: Thu, Feb 15, 2018 at 4:30 PM
Subject: Re: [Lava-users] [HW target questions] Pointers from Lava
test suite to the HW target
To: Zoran S <zoran.stojsavljevic.de(a)gmail.com>
Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org>
Not exactly.
1/ The process that is deploying, booting and testing a DUT (Device
Under test) is called lava-run.
lava-run environment variables are controlled by /etc/lava-server/env.yaml
By default, all environment variables are removed and only a small set
of variables are added.
This helps to make executions reproducible between dispatchers and instances.
So if you need an environment variable to be set, then you have to add
it to /etc/lava-server/env.yaml
2/ On the DUT itself, by default, we don't add or change any
environment variable. Because that's the user responsibility.
However, if /etc/lava-server/env.dut.yaml does exists, it will be used
to add environment variables to the DUT shell.
To create the list of environment variables to add to the DUT, we take
the full environment from lava-run (as defined by
/etc/lava-server/env.yaml) and we apply the rules from env.dut.yaml.
I hope that does help you to understand how environment is setup in lava.
Rgds
On Wed, Feb 14, 2018 at 2:04 PM, Zoran S
<zoran.stojsavljevic.de(a)gmail.com> wrote:
> https://gitlab.com/cip-project/cip-testing/testing/issues/99
>
> Also from:
> https://lists.cip-project.org/pipermail/cip-dev/2017-July/000338.html
>
> At the end of test issue #99, I added the solution to this problem.
>
> Lava does NOT read VM's ENV variables. It ignores them. Lava reads
> /etc/lava-server/env.yaml as setup proxy file!
>
> Included there also /etc/lava-server/env.yaml file example.
>
> It could be done also DIRECTLY (every time bringing up the VM) using
> python, tapping into the urllib3 python code (example given):
> https://stackoverflow.com/questions/31151615/how-to-handle-proxies-in-urlli…
>
> I've tried this, using in-line python interpreter, it worked.
>
> Zoran
Hello Lava Users,
Trying to reproduce LAVA installation in our lab.Was able to
successfully test deploy boot and test through nfs metod.
But having difficulty when device is booted with *preinstalled Debian
or OpenEmbedded images and ** we just want to execute tests on it (no
need to create images at moment).*
Can have any reference documents or templates to refer when just want
to execute tests on device.
Thanks,
Hemanth.
Hello to the Lava users,
I am the new Lava user. My aim is to use Lava (for now V1) setup for my
testing, from the beginning just to hook-up my Beagle Bone Black (BBB) to
Lava worker, and from Lava apache to set the proper context for testing BBB
HW.
As I am reading Lava framework, I got the following impression about the
test suite:
[1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup;
[2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and
POFF HW platform);
[3] I need to hook-up ser2net interface (which I already have working over
TCP) to the Lava. so Lava can control it;
[4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which
will be FTPed and set in memory for board setup and testing).
Question 1: Does manual have some Beagle Bone Black U-Boot default scripts,
which should be provisioned to the BBB U-Boot for the correct Lava U-Boot
behavior?
Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some
explanation as working example how to do these points?
Question 3: Anything else I missed for the proper Lava test setting?
Thank you in advance,
Zoran
Hi Everyone,
If i execute a LXC Job. If this job execution failed due to any
reason, then in that case LXC-stop is not called, directly lxc-destroy is
called by which LXC instance is still running on system and consumes memory
and Space.
How we can can make sure that this instance destroys with Job completion
either Failed/Passed/Incomplete.
--
Thanks & Regards
Chetan Sharma
Is there a way to make user logins to work whether you're connecting
over HTTP or HTTPS on the same instance?
I know that to get user logins to work without https, you have to add
this to /etc/lava-server/settings.conf:
"CSRF_COOKIE_SECURE": false,
"SESSION_COOKIE_SECURE": false,
But it would be nice if user logins would also work over https at the same time.
The use case for this is an internal LAVA instance that doesn't have
https so internal connections are all over http. The same instance is
also available to the outside world via an nginx reverse proxy with
TLS termination, so connections from outside are over https.
Can it be made to work for both internal (http) and external (https)
connections?
Thanks,
Kevin
Hi Guys:
When I am doing a multi-node testing, I create one job definition liking below. For example:
Sub-job 1 finished booting and testing, but sub-job 2 is on-going booting. So sub-job 1 will
Remove the template file like <lava_dipatcher>/tmp/overlay****, that will cause sub-job 2 could NOT download
The overlay**** file, sub-job 2 failed in the end. My question is how to do sync between multi-node in the job
Definition?
My job definition:
protocols:
lava-multinode:
roles:
foo:
tags:
- board1
device_type: **********
context:
grub_method: centos
grub_installed_device: (hd1,gpt1)
count: 1
bar:
tags:
- board2
device_type: **********
context:
grub_method: centos
grub_installed_device: (hd2,gpt1)
count: 1
timeout:
minutes: 6
job_name: centos openjdk test
timeouts:
job:
minutes: 1500
action:
minutes: 50
connection:
minutes: 30
priority: medium
visibility: public
actions:
- deploy:
role:
- foo
- bar
kernel:
url: http://********
type: zimage
os: centos
timeout:
minutes: 80
to: tftp
- boot:
timeout:
minutes: 40
role:
- bar
method: grub
commands: centos_installed
auto_login:
login_prompt: 'login:'
username: root
password_prompt: 'Password:'
password: root
prompts:
- 'root@localhost ~'
transfer_overlay:
download_command: rm -f /root/overlay* ; ifconfig ; wget -S --progress=dot:giga
unpack_command: tar -C / -xaf
parameters:
shutdown-message: "reboot: Restarting system"
- boot:
timeout:
minutes: 40
role:
- foo
method: grub
commands: centos_installed
auto_login:
login_prompt: 'login:'
username: root
password_prompt: 'Password:'
password: root
prompts:
- 'root@localhost ~'
transfer_overlay:
download_command: rm -f /root/overlay* ; ifconfig ; wget -S --progress=dot:giga
unpack_command: tar -C / -xaf
parameters:
shutdown-message: "reboot: Restarting system"
- test:
role:
- foo
- bar
timeout:
minutes: 50
definitions:
- repository: ssh://**********/test-definitions
from: git
branch: **********
path: automated/linux/openjdk/openjdk-smoke.yaml
name: openjdk-smoke
Thanks
B.R.
Guoqi
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.