Hi all,
I run into some unexpected behavior when it comes to LAVA job IDs reported by the "lavacli jobs sumit" command for multi node tests.
What I get is a list of newline separated job IDs like:
lavacli jobs submit <my-job-description> 132.0 132.1
To my understanding this tries to express that 132.1 is a sub job of 132. OK, but this is a problem if I now try to download the junit report for the second job (=132.1).
It seems 132.1 is not a valid job ID (API wise), it has to be translated to 133 to work properly.
This is still doable, but I'm unsure if I can relay on 133 really being the 132.1 job in case there are several job submissions at the same time.
Is that a bug of lavacli? What is the reasoning for returning a sub job ID which seems to be invisible to the rest of the LAVA infrastructure / API?
I'm currently running lavacli 1.2-1, as shipped by Debian 12.
Any input welcome...
Best regards, Florian
Hi Florian,
I am unsure I am qualified to answer as I have limited experience with multinode jobs, but that is what it seems like youre working with (please correct me if that assumption is wrong).
When looking at a (multinode) job itself, it will have what I call a "display id" and a "functional id". The display id is the 132.0 and 132.1 in your presented case, but the functional ids are 132 and 133, being that when requesting job information via lavacli or the RPC api, you use the functional id. I don't think it's a bug, but either a weird intentional implementation or a limitation (old or current, I am unsure) of something else.
This can be quite bothersome I think if you are going to submit several jobs at one time, and the only way to predict what the ids are going to be in advance is knowing how many jobs are being submitted, and how many devices are involved in each test.
Again, my experience with multinode is limited as I don't use, nor need to use, multinode tests. As such, I may be wrong or only partially correct, so take my words with a grain of salt.
Best regards, Michael
Hi Michael,
might it be that used the wrong button in your mail client? Your answer reached the list but not my personal inbox... Luckily I just noticed the mail on the list. Anyhow, here we go:
On Mon, 2024-08-19 at 23:57 +0000, Michael Peddie wrote:
Hi Florian,
I am unsure I am qualified to answer as I have limited experience with multinode jobs, but that is what it seems like youre working with (please correct me if that assumption is wrong).
Correct. I'm working with multinode jobs here. I hoped that the subject would made that clear...
When looking at a (multinode) job itself, it will have what I call a "display id" and a "functional id". The display id is the 132.0 and 132.1 in your presented case, but the functional ids are 132 and 133, being that when requesting job information via lavacli or the RPC api, you use the functional id. I don't think it's a bug, but either a weird intentional implementation or a limitation (old or current, I am unsure) of something else.
Meanwhile I'm quite sure it's not a bug in lavacli itself, more a confusing (and maybe partially broken) thing API wise.
lavacli is able to deal with both kind of job IDs. I have no idea how they are called so I keep your wording. For example "lavacli jobs logs" is able to handle both of them, so "functional ids" and "display ids".
Taking the scheduler/job/<jobid> API endpoint as additional example: Both types of IDs work. You will get the right job log.
On the other hand the api/v0.2/jobs/<jobid>/junit endpoint only supports "functional ids", so 133 but not "display IDs" like 132.1.
This can be quite bothersome I think if you are going to submit several jobs at one time, and the only way to predict what the ids are going to be in advance is knowing how many jobs are being submitted, and how many devices are involved in each test.
Exactly. I'm searching for a way/API to get this done properly. I want to download the junit report from each sub test / node.
I get the "display IDs" from "lavacli jobs submit" command, but how to translate them? Or the other way around: Is it a bug / missing feature that the junit endpoint above does not support both ID types?
Again, my experience with multinode is limited as I don't use, nor need to use, multinode tests. As such, I may be wrong or only partially correct, so take my words with a grain of salt.
Best regards, Michael _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
lava-users@lists.lavasoftware.org
-
Florian Bezdeka -
Michael Peddie