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