lava-users

lava-users@lists.lavasoftware.org

2 participants
930 discussions

by Larry Shen

Hi, there, If lava in some place possible to find who cancel a job? Or use lavacli or manual cancel a job? Or for which detail reason, the job was canceled? We are struggling to find why my job canceled sometimes, not sure someone not carefully do it or our external program by chance do it, especially when there are many people used the same master. Regards, Lary

5 years, 4 months

Question about send delay for serial.

by Larry Shen

Sometimes for some device, when lava enter "/lava-55904/bin/lava-test-runner /lava-55904/0" It looks it will print: -sh: /lava-55904/bin/lava-test-runnera-55904/0: No such file or directory Looks some character miss. We increases the test_character_delay, looks useful, but I'm interested about the details, so for next which you mentioned in the code: What exactly "slow serial problems(iPXE)" mean, could you explain more about it or any reference materteral I can had a look? Then I could know: yes, it's exactly the same problem I have. >>> Extends pexpect.sendline so that it can support the delay argument which allows a delay between sending each character to get around slow serial problems (iPXE). pexpect sendline does exactly the same thing: calls send for the string then os.linesep.

5 years, 4 months

About health check behavior?

by Larry Shen

Hi, there, Frequently, I found when a job becomes incomplete there will immediately a health check job on that device happen automatically to check the status of the device. But strange, some times I won't see that healthy check job. So, my question is: when I see that healthy check job, is it just by chance? Or it really designed that there will be a healthy check after incomplete job? Thanks. Regards, Larry

5 years, 4 months

"Where're my failed tests, dudes?"

by Paul Sokolovsky

Hello, I hope that the mail subject set up an easy, cheerful background for this discussion ;-). This definitely goes into the "stupid questions" department. My plan was to collect "evidence"/feedback from my colleagues, then at the Connect BUD20, crash into LAVA/QA rooms and ask what I/we are doing wrong. As circumstances changed, but the "testing debt" only builds up, there's little choice but to try figure out these matters over a much narrower pipe. So, before proceeding to the question per se, let me theorize that the reasons why such questions come up at all, are sufficient differences in the intended LAVA usage patterns. In other words, how I'd like to use LAVA on the LITE team side may differ from how LAVA team intends it to be used, or how QA team uses (the biggest user would it be). The issue? How I'd intend to use it is IMHO one the most basic ways to use a test system. So, what's that usage? Well, I'm not much interested in "interactive" use (submit jobs manually from my machine). Our interest is in unattended automated CI, of which the testing system is the second half after the build system. So let me remind how our build system, Jenkins, works. Normally, it just builds binaries and uploads them to a publishing server. It's invisible to me in this phase, and my engineering work goes uninterrupted. But when a build fails, I get an email with details about a failure. And I'll continue to get them while it continues to fail. So, the only option I have is to go see the failure, investigate, and fix it. When I arrive at Jenkins, I can easily see which jobs failed and which not, then within each job, see which builds failed and which succeeded. That's very easy, because failed things are red, and successful things are green. So, we've now arrived at the main question of this email - Why I don't seem to be able to use LAVA in the same way? Why LAVA offers only "Incomplete" and "Complete" job statuses? "Incomplete" is understood - it's an infrastructure failure, such a job is definitely "failed". But "Complete" doesn't give me any useful information whether the job succeeded or failed. Because a "Complete" job may still have any number of tests failed. And that's exactly the "last mile" LAVA misses to go: for any test job, I want to see a cumulative number of test cases which failed, straight at the page like https://lite.validation.linaro.org/scheduler/alljobs . Then, I'd like to filter out jobs which has this number >0. Then I'd like to receive a notification only for "failed" jobs, "failed" defined as "status != Complete OR failed_testcases > 0". So, what am I missing and how to make LAVA work like the above? Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

5 years, 4 months

2020.02: docker in docker support for fastboot docker deploy

by Stephen Lawrence

Hi, After the recent Linaro Tech Day LAVA presentation I have been looking into the new support in LAVA v2020.02 for deploying fastboot on the host to docker rather than lxc. I am running my lava worker in a docker image derived from the linaro lava docker images and so wanted to ask if the new feature supported docker in docker for the fastboot containerisation? Regards Steve

5 years, 4 months

Submit Job

by Nikolina nici_nigel

Hello, I just started working with hardware, firmware and lava. You have a big documentation, but for me it's sometimes difficult to find something. I wanted to submit a job on just one device like my "bbb-03" and not on every beaglebone-black. Is there a device-tag to choose a device like "device_type: "? My next question is if there is also a worker tag for a job submit? For example I just want to run all "beaglebone-black" on my "worker2". Is there also a list of all job submissions tags with examples? I just found the one for the "actions" part. I'm sorry for disturbing and maybe the stupid question. But thank you for your answer in advance. I wish you a nice day

5 years, 4 months

Delaying LAVA Release

by Remi Duraffort

Hello, As you know, we are trying to release a new version of LAVA every month. We are delaying this month release (2020.03) due to some issues and crashes that we found in the last days. Issues where found on staging.vlo, lavafed and meta-lava, proving that the CI is working. Where are currently working on fixing the issues and proving that LAVA is ready for release. The next release should be ready for the end of next week and would be called 2020.04. Rgds -- Rémi Duraffort LAVA Architect Linaro

5 years, 4 months

Confusion between LAVA job definition "name" vs UI "description"

by Paul Sokolovsky

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/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

5 years, 4 months

Sample docker-compose.yml file to detect adb devices in "lava-dispatcher"

by koti koti

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

5 years, 4 months

test/tests execution on provision (booted) board with out "-boot" section. (Basically I am skipping deploy and boot sections)

by koti 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

5 years, 4 months

← Newer
1
...
27
28
29
30
31
32
33
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users