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&conditions=testjob__description__ne__foo
> >
> > 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/models.py#L1364
> https://git.lavasoftware.org/lava/lava/-/blob/master/lava_scheduler_app/models.py#L1159

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

_______________________________________________
Lava-users mailing list
Lava-users@lists.lavasoftware.org
https://lists.lavasoftware.org/mailman/listinfo/lava-users