lava-users April 2020

lava-users@lists.lavasoftware.org

14 participants
22 discussions

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

4 years, 8 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

4 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users April 2020