Hello Paul,
thanks for your mail.
As said by Milosz, the job_name is saved into the TestJob.description field.
I agree that the name has been badly chosen but fixing this will generate a lot of work for no real benefits.
We can: * rename the database field. In this case we will have to change a lot of places in the source code and in the API return values. * rename job_name to description in the job definition. In this case, that's mainly some work for users.
So in both situations users will have to update either job definition or api scripts.
So I believe that this is way too much work for no real benefit.
Thanks
Le mer. 1 avr. 2020 à 14:50, Paul Sokolovsky paul.sokolovsky@linaro.org a écrit :
Hello Milosz,
On Wed, 1 Apr 2020 11:01:17 +0000 Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
[]
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).
https://lite.validation.linaro.org/results/query/+custom?entity=testjob&...
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.
This is confirmed theory, not just conjecture :)
https://git.lavasoftware.org/lava/lava/-/blob/master/lava_scheduler_app/mode...
https://git.lavasoftware.org/lava/lava/-/blob/master/lava_scheduler_app/mode...
Thanks for confirming that.
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.
Maybe the simplest solution would be changing this field in YAML and calling it 'description' instead of 'name'? For some time (transition period) both ways should be possible but in the long run we would stop using 'name'.
Hmm, at first look, this seems like "upside down" solution. A model of LAVA I would have is that the "primary external interface" of LAVA is job/test definitions and ways to submit them (APIs/tools). The rest is "merely" a "UI frontend". Saying, after so many years, that UI frontend has got it right, while job specification format was wrong all this time is ... strange. Especially if we border on saying "DB has got it right", with DB field names being a hidden implementation detail.
Migration cost would definitely be high too, with many jobdefs in the wild, which would need to be updated (or if they don't, confusion persists). In my plan, no active updates on users' side is needed.
Also as I mentioned in the original email, for me typical examples of name vs description:
name: zephyr-net-ping #823-2ac65a24 description: Ping Zephyr dumb_http_server sample with packets of different size and interval.
That said, I don't know. If YAML's field was called "description" in the first place, we all would take for granted that it is "short (not too long) sequence of characters", and there certainly wouldn't be the confusion described.
So, in the end, the relatively high migration cost (to the users) is the main concern.
milosz
Thanks, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users