Hello,
I recently went "on a spree" to submit a number of LAVA UI issues
either accumulated in my mind or just caught on exhaustive search for a
feature I miss. They are at
https://git.lavasoftware.org/lava/lava/-/issues?scope=all&author_username=p…
and I believe all of them worth fixing (and don't bring in concerns
like backward compatibility). So, they're up for triaging by the
maintainers and feedback from the community to confirm they're indeed
such. (Then, I'd be able to help with addressing them, as much as I
can).
There're more issues, about which I'm less sure. So, instead of
submitting such as bugs, let me ask for a feedback in the email,
starting with this one:
When you prepare a job definition YAML to submit to LAVA, in it you
something like:
job_name: 'zephyr-net-ping #823-2ac65a24'
It may be not immediately obvious, but what you had as a "job name" in
the YAML, ends up as a "description" when you visit job list in the
LAVA UI (E.g. at https://validation.linaro.org/scheduler/alljobs).
"Is it that much of a difference? Most people wouldn't even notice!"
you may think, and I can only second that. I for one never paid
attention to that for on-and-off, mostly very light usage of LAVA for
some 10 years (i.e. I started yet with the previous version which
might look different at all).
And indeed, it won't make any difference until may want to start
querying job results. And I would like to share a story of what that
difference costed me.
Here's a patch I submitted in June 2017:
https://git.linaro.org/ci/job/configs.git/commit/lite-aeolus/lava-job-defin…
with a commit message and inline comment of: "For some reason, LAVA
doesn't allow to query by real job name, so we need to duplicate it as
metadata."
Here's another patch which I submitted based on the analysis I
present here: https://review.linaro.org/c/ci/job/configs/+/34677
So, for almost 3 years I lived with a misconception that LAVA can't
query by a job name.
Call it an extreme case. Call me dumb. Say that there's autocompletion
for field names and any person with some agility of mind would type
different characters and would notice "description" as available field.
Yeah, I did all that. But I'm with me from 3 years ago: for me, "job
name" is "zephyr-net-ping #823-2ac65a24". "job description" would be
something like "Ping Zephyr dumb_http_server sample with packets of
different size and interval". To the best of my knowledge, there's no
such a field in jobdef YAML to include such a description, and I
definitely don't include it in my jobs, so never would I try to search
anything in "description", for the lack thereof in my jobs.
Unless I have too much time to apply random "genetic algorithms" to
LAVA UI or just do exhaustive search thru it. Which I usually don't
have time for (I'm not a test engineer, but a developer, with "test
that code" always in backlog). Until recently, when testing debt has
really become pressing, and I decided to face all "skeletons in closed"
I had with LAVA ;-).
So, even 3 years haven't passed until I "did my homework" on searching
jobs by name. But my point would be that there should be no need for any
"homework" regarding these matters, it all should just work right away
without double-thinking and guesswork.
And I would consider this a genuine bug. I'm less sure about fixing
though. Because it's not a matter of just changing a few UI labels.
It's more pervasive, as e.g. this URL shows:
https://lite.validation.linaro.org/results/query/+custom?entity=testjob&con…
And seeing that URL, one can actually conjecture how that "description"
appeared in the UI: it's actually name of the database table. Which
just bled into system public interface. Too bad, because another public
interface uses "job name" for that field, and internal naming like db
fields shouldn't prevail.
Anyway, I'm not going to argue that DB should be migrated, and it won't
help, as we definitely don't want to break existing queries, etc. So,
the only way to fix that would be to alias existing "description" to
clearer "name" (or "jobname", "job_name"), and perform mapping on DB
access. I'm note sure if it's worth. Based on my experience, I'd go
for it, and it doesn't sounds like rocker science. But only
maintainers could imagine how kludgy it would be in the actual LAVA
database and if it's worth it, taking into account other tasks and
priorities.
Thanks for reading the story (rant?).
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
I am facing the issue while porting Host's "adb-devices" to
lava-dispatcher docker.
Please can some one provide the right steps to detect "adb-devices" in
"lava-dispatcher" docker?
Current steps: (still my lava-dispatcher fail to detect the Host's
"adb-devices")
###########
1. Lauch the LAVA-lab using "docker-compose up" from the repo "
https://github.com/danrue/lava-docker-compose.git"
2. add "/dev/bus/usb" , "/etc/udev/rules.d" and "privileged: True" to
"lava-dispatcher" i.e
" dispatcher:
image: lavasoftware/lava-dispatcher:2019.12
container_name: lava_dispatcher
privileged: True
devices:
- /dev/kvm # needed for QEMU
- /dev/net/tun # needed for QEMU
- /dev/bus/usb
cap_add:
- NET_ADMIN # needed for QEMU
environment:
- "DISPATCHER_HOSTNAME=--hostname=dispatcher"
- "LOGGER_URL=tcp://server:5555" # url to send logs
- "MASTER_URL=tcp://server:5556" # url of lava master
volumes:
- '/boot:/boot:ro'
- '/lib/modules:/lib/modules:ro'
- '/dev/bus/usb:/dev/bus/usb'
- '/etc/udev/rules.d:/etc/udev/rules.d'"
3. Run the command #docker-compose up
4. Login to lava-dispatcher #docker exec -it <dispatcher-name" bash
#apt-get update;apt-get install android-tools-adb
android-tools-fastboot usbutils
#adb devices
Can some one let me know the steps to detect my host's "adb-devices" in
lava-dispatcher's docker?
Regards,
Koti
Hi,
I am able to boot and run the tests with Provisioned(booted) board using
attached YAML i.e "working_yaml.yaml".
But, I am facing the issue while running the tests on Provisioned (booted)
board with out "-boot" section. (you can see my YAML file as mentioned
below which I have used now)
Please can some one help me for the same?
1. Basically I am facing the connection issue with out "-boot" section.
2. Why this dependency to connect terminal for boot section ? ( I am
able to connect serial port when I use "-boot" section in yaml file)
3. Please can some one provide me right YAML to run my tests with out
"-boot" section. ( to resolve serial connection issue with out "-boot"
section)
"
device_type: beaglebone-black
job_name: begalbone healthcheck
timeouts:
job:
minutes: 30
action:
minutes: 15
connection:
minutes: 5
priority: medium
visibility: public
context:
test_character_delay: 10
actions:
#- boot:
# timeout:
# minutes: 15
# method: minimal
## reset: false
## auto_login:
## login_prompt: '.* login:'
## username: root
# prompts:
# - root@dragonboard-410c:~#
- test:
interactive:
- name: reset
prompts: ["#"]
script:
- name: reset
command: reset
"
Regards,
Koti
Interesting topic, one question:
What will the new LAVA rest api look? a) or b) ? I wish it could b), then we could ease our master's pressure...
a) Django-rest-framework alike, synchronous
b) Tornado alike, asynchronous
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org
Sent: Wednesday, March 11, 2020 8:00 PM
To: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Lava-users Digest, Vol 19, Issue 2
Caution: EXT Email
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."
Today's Topics:
1. LAVA RESTful API feedback and plans (Stevan Radakovi?)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Mar 2020 09:17:00 +0100
From: Stevan Radakovi? <stevan.radakovic(a)linaro.org>
To: "lava-users(a)lists.lavasoftware.org"
<lava-users(a)lists.lavasoftware.org>
Subject: [Lava-users] LAVA RESTful API feedback and plans
Message-ID: <34b9c19d-b0eb-2d85-0c85-a4e536a1812e(a)linaro.org>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello community,
With the LAVA release of 2020.02 we now have a REST API framework that we fell covers all the functionalities of the already existing XMLRPC API.
Since the long-term plan is to drop the XMLRPC support, we now encourage everyone to use REST and we also would like to hear feedback about any additional features that you'd like to see as part of the REST API.
Our plan is to slowly move lavacli
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.lava…> project to use REST API exclusively, after that we will schedule the deprecation of the XMLRPC API.
Cheers,
--
Stevan Radakovi? | LAVA Engineer
Linaro.org <https://eur01.safelinks.protection.outlook.com/?url=www.linaro.org&data…> ? Open source software for ARM SoCs
Hi,
Right now I am trying to run tests on Provisioned(booted) board with out
using physical Power switches .
But, I am seeing below soft reboot lines while using the attached YAML
file,
"
start: 1 minimal-boot (timeout 00:15:00) [common]
start: 1.1 connect-device (timeout 00:15:00) [common]
[common] connect-device Connecting to device using 'telnet ser2net 5001'
end: 1.1 connect-device (duration 00:00:01) [common]
start: 1.2 reset-device (timeout 00:14:59) [common]
start: 1.2.1 send-reboot-commands (timeout 00:14:59) [common]
No soft reboot command defined in the test job. Using defaults.
reboot
reboot
reboot -n
reboot -n
reboot -nf
reboot -nf
"
I want to change my soft reboot command as "reset" instead of
"reboot"/"reboot -n"/"reboot -nf".
Please can some one let me know as how can I change default soft reboot
command to "reset" ?
Regards,
Koti
Hi,
I have successfully booted the Beagelbone board from "
https://github.com/danrue/lava.therub.org" . (corresponding ymal is
https://github.com/danrue/lava.therub.org/blob/master/server-overlay/etc/la…
)
But, now I am trying to run one more scenario (may be new scenario and not
sure is it supported by LAVA lab?) i.e
1. Run the tests on already provisioned (boot) beagelbone board. (Basically
I am skipping the booting mentioned and trying to run on the already
provisioned/boot board)
a) boot the target
b) Connect Board to LAVA lab
c) Just check the login prompt ("#") is available or not?
c) Run the using below test definition file (Basically this test
definition file runs "ls"/"ifconfig" commands in the already
provisioned(boot) board).
"
device_type: beaglebone-black
job_name: beaglebone-black healthcheck
timeouts:
job:
minutes: 10
action:
minutes: 5
priority: high
visibility: public
actions:
- test:
interactive:
- name: ls test
prompts: ["#"]
echo: discard
script:
- name: ls
command: ls
successes:
- message: "ls simple test successes"
failures:
- message: "TIMEOUT"
exception: InfrastructureError
error: "ls command failed"
- name: ifconfig
command: ifconfig
- name: wait for the prompt
command:
"
I have tried to run this. But, my test failed with the error ""Connection
closed"" (Attached screenshot)
Can some one let me know solution to fix this error?
Regards,
koti
Hello community,
With the LAVA release of 2020.02 we now have a REST API framework that
we fell covers all the functionalities of the already existing XMLRPC API.
Since the long-term plan is to drop the XMLRPC support, we now encourage
everyone to use REST and we also would like to hear feedback about any
additional features that you'd like to see as part of the REST API.
Our plan is to slowly move lavacli
<https://docs.lavasoftware.org/lavacli/> project to use REST API
exclusively, after that we will schedule the deprecation of the XMLRPC API.
Cheers,
--
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs
Hi, lava team!
First question:
I'm working with fastboot device, is it possible after test part put device again to fastboot mode, run some fastboot command ( not to flash ), boot again, run test.
job steps:
1. deploy lxc
2. boot lxc
3. test lxc
4. deploy fastboot ( put to fastboot )
5. boot fastboot device
6. run test
7. reboot and put device to fastboot mode
8. run fastboot commands
9. continue run test.
Can you give any advice how to do it?
Better to able reboot device inside test. I tried to reboot device from test part, lava just stuck and wait when reboot action will end. But looks like it does not recognize end.
Second question:
In job have lxc namespace and device namespace, how to run command_action from host os, not lxc?
Best regards,
Ilya Feduisv
