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.
Hello Lava Team,
I have created some Lava jobs that use our proprietary Flasher, based on a DFU connection.
As our flasher is not a "standard" flasher, I have adapted the boot process to be able to use our flasher.
I use the boot method "minimal" to achieve this.
To call our flasher script, I have used the script called by the method "power_on". This is defined in the device configuration.
Find below an extract of the device content :
.......................................................................................
..
..
{% set hard_reset_command = '/usr/bin/pduclient --daemon localhost --hostname lava_pdu_01.lme.st.com --command reboot --port 1' %}
{% set power_off_command = '/usr/bin/pduclient --daemon localhost --hostname lava_pdu_01.lme.st.com --command off --port 1' %}
{% set power_on_command = '/root/git/lava-config/scripts/flash_stm32_programmer.sh -u lava_pdu_01.lme.st.com -p 1 -d usb1 -b ds378_2.lme.st.com -s 4_5_6 -f /tmp/test' %}
{% set connection_command = 'telnet localhost 2001' %}
..
..
.......................................................................................
This works correctly for a "static" configuration. The settings for the flasher are defined outside Lava by a script that configure the flashing parameters.
The "power_on" script reads these parameters, and launch the flashing on the board.
My problem now, is when I launch simultaneously jobs on several boards that requires different flashing binaries version.
I am unable to indicate to each boards which binary version to be used by our flasher.
The best way would be to pass parameters in the job to indicate which binary version has to be used by the flasher.
This could be done in the "deploy action" and pass to the "power_on" command, but I don't know how to implement it.
I don't know also if it is possible to do that easily ?
Find below my job definition.
###### Job definition ##############
actions:
- deploy:
timeout:
minutes: 5
to: ssh
os: oe
device:
- boot:
method: minimal
failure_retry: 2
auto_login:
login_prompt: 'login:'
username: root
prompts:
- 'root@stm32mp1'
timeout:
minutes: 10
transfer_overlay:
download_command: sync && sleep 15 && wget
unpack_command: tar -C / -xzf
- test: ... #############################
Thanks to support me.
BR
Philippe
When using LAVA inside a docker container, the LXC support adds lots
of unnecessary overhead since the docker images are already made to
include the necessary tools. So having another container is pointless.
Even worse, LXC doesn't work inside docker anyways.
The LXC support should be made optional for a given LAVA install.
Until LXC can be disabled, projects like lava-docker[1] simply cannot
support fastboot devices which is a major problem.
Kevin
[1] https://github.com/kernelci/lava-docker/
Hi,
I have lava-master and lava-slave v2018.1 installed, and a qemu device
added. Test job can be scheduler. Then I followed
https://validation.linaro.org/static/docs/v2/pipeline-server.html#using-zmq…
to enable ZMQ authentication.
Certificates were generated correctly, public certificates were copied
to master and slave respectively. With the following configs:
lava-master
```
MASTER_SOCKET="--master-socket tcp://*:5556"
LOGLEVEL="DEBUG"
ENCRYPT="--encrypt"
MASTER_CERT="--master-cert
/etc/lava-dispatcher/certificates.d/master.key_secret"
SLAVES_CERTS="--slaves-certs /etc/lava-dispatcher/certificates.d/"
```
lava-slave
```
MASTER_URL="tcp://192.168.11.214:5556"
LOGGER_URL="tcp://192.168.11.214:5555"
HOSTNAME="--hostname lava-slave1"
LOGLEVEL="DEBUG"
ENCRYPT="--encrypt"
MASTER_CERT="--master-cert /etc/lava-dispatcher/certificates.d/master.key"
SLAVE_CERT="--slave-cert /etc/lava-dispatcher/certificates.d/slave1.key_secret"
```
After lava-master and lava-slave restarted, I see the following logs.
Seems the connect was established, but lava-logs went offline.
lava-master
```
2018-01-30 11:05:50,260 DEBUG lava-slave1 => PING(20)
2018-01-30 11:05:52,086 DEBUG lava-master => PING(20)
2018-01-30 11:06:08,728 DEBUG lava-logs => PING(20)
2018-01-30 11:06:10,261 INFO scheduling health checks:
2018-01-30 11:06:10,270 DEBUG -> disabled on: lxc, qemu
2018-01-30 11:06:10,271 INFO scheduling jobs:
2018-01-30 11:06:10,272 DEBUG - lxc
2018-01-30 11:06:10,292 DEBUG - qemu
2018-01-30 11:06:10,332 DEBUG lava-slave1 => PING(20)
2018-01-30 11:06:12,115 DEBUG lava-master => PING(20)
2018-01-30 11:06:20,252 INFO [POLL] Received a signal, leaving
2018-01-30 11:06:20,254 INFO [CLOSE] Closing the controler socket
and dropping messages
2018-01-30 11:06:21,203 INFO [INIT] Dropping privileges
2018-01-30 11:06:21,204 DEBUG Switching to (lavaserver(114), lavaserver(119))
2018-01-30 11:06:21,204 INFO [INIT] Marking all workers as offline
2018-01-30 11:06:21,209 INFO [INIT] Starting encryption
2018-01-30 11:06:21,211 DEBUG [INIT] Opening master certificate:
/etc/lava-dispatcher/certificates.d/master.key_secret
2018-01-30 11:06:21,238 DEBUG [INIT] Using slaves certificates from:
/etc/lava-dispatcher/certificates.d/
2018-01-30 11:06:21,245 INFO [INIT] LAVA master has started.
2018-01-30 11:06:21,246 INFO [INIT] Using protocol version 2
2018-01-30 11:06:41,247 WARNING lava-logs is offline: can't schedule jobs
2018-01-30 11:07:01,255 WARNING lava-logs is offline: can't schedule jobs
2018-01-30 11:07:04,433 INFO lava-slave1 => HELLO
2018-01-30 11:07:04,433 WARNING New dispatcher <lava-slave1>
2018-01-30 11:07:09,450 DEBUG lava-slave1 => PING(20)
2018-01-30 11:07:21,260 WARNING lava-logs is offline: can't schedule jobs
2018-01-30 11:07:29,477 DEBUG lava-slave1 => PING(20)
2018-01-30 11:07:41,265 WARNING lava-logs is offline: can't schedule jobs
```
lava-slave
```
2018-01-30 11:06:10,283 DEBUG PING => master (last message 20s ago)
2018-01-30 11:06:10,335 DEBUG master => PONG(20)
2018-01-30 11:06:30,356 DEBUG PING => master (last message 20s ago)
2018-01-30 11:07:04,379 INFO [INIT] LAVA slave has started.
2018-01-30 11:07:04,380 INFO [INIT] Using protocol version 2
2018-01-30 11:07:04,390 INFO [INIT] Starting encryption
2018-01-30 11:07:04,390 DEBUG Opening slave certificate:
/etc/lava-dispatcher/certificates.d/slave1.key_secret
2018-01-30 11:07:04,413 DEBUG Opening master certificate:
/etc/lava-dispatcher/certificates.d/master.key
2018-01-30 11:07:04,414 INFO [INIT] Connecting to master as <lava-slave1>
2018-01-30 11:07:04,415 INFO [INIT] Greeting the master => 'HELLO'
2018-01-30 11:07:04,440 INFO [INIT] Connection with master established
2018-01-30 11:07:04,442 INFO Master is ONLINE
2018-01-30 11:07:04,443 INFO Waiting for instructions
2018-01-30 11:07:09,450 DEBUG PING => master (last message 5s ago)
2018-01-30 11:07:09,455 DEBUG master => PONG(20)
```
>From django admin console, I see lava-slave1 still is online, but
both lava-master and lava-logs workers went offline, and it stopped
scheduling test job. Have you guys ever see/hit this issue? Any advice
and suggestions would be appreciated.
Thanks,
Chase
Hi All,
We use IOZone test to measure performance of our DUT
Same command executed several time in a Lava session provide a diversity of results
iozone -az -i0 -i1 -I -e -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -f /mnt_emmc//tmp/iozone.tmp
Example1:
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 5053 4420 12471 12137
102400 16 5070 5218 22101 22207
102400 512 11733 12630 40799 40862
102400 1024 11446 11494 39982 39976
102400 16384 13839 14235 42093 42094
Example 2:
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 5088 5006 13496 13095
102400 16 5395 5549 17199 17220
102400 512 9203 10038 27819 27586
102400 1024 9382 8482 32514 32430
102400 16384 13569 13986 41992 42081
When same command is executed without LAVA with same DUT, results are more homogeneous (similar to exemple1) and permit to define clear targets
How to reduce interaction from Lava to measure performance of DUT ?
Is it possible to disable some checks / interactions with DUT during execution of each test (around 3 / 4 minutes) ?
Thanks in advance for your answer
Florence Rouger-Jung
Hi, our boards are powered via PDU and before flashing with pyocd, they need to be powered up first. I defined power_on_command in the device dictionary, but it is ignored.
It looks like an only limited set of methods add ResetDevice action to the pipeline and pyocd is not among them. Contrarily, if defined, power_off command always gets invoked because it is added by FinalizeAction to every test.
I'm wondering if there is any way to issue the power-on command without modifying the dispatcher pipeline source code.
Thanks,
Andrei Narkevitch, Cypress Semiconductor
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
Hi Everyone
Can anyone share sample Yaml File and Usecase using
"prepare-scp-overlay" using MultiNode.
Some calls can only be made against specific actions. Specifically, the
prepare-scp-overlay action needs the IP address of the host device to be
able to copy the LAVA overlay (containing the test definitions) onto the
device before connecting using ssh to start the test. This is a
complex configuration
to write.
--
Thanks & Regards
Chetan Sharma
