Enable Qualcomm lab for new KernelCI infra

[padovan]

Qualcomm wants to bring their lab to the new KernelCI infra. Let's use this ticket to drive the discussions.

@EmbeddedAndroid what tech are you using for the lab? LAVA? If it is LAVA, it should quite easy as we support that runtime already. If it is something else, we can walk you through how to implement the runtime. (doc for all this is in the works).

API token request: #357

[EmbeddedAndroid]

@padovan We are using LAVA, our public instance can be found here: https://lava.infra.foundries.io/scheduler/

[JenySadadia]

Hi @EmbeddedAndroid
To enable Qualcomm lab in KernelCI, we would need a lab token and its description.
Please have a look at https://github.com/kernelci/kernelci-pipeline/blob/main/doc/connecting-lab.md#token-setup.
Could you please create one for KernelCI?

[EmbeddedAndroid]

Hi @JenySadadia

Sure no problem, I'm going to loop in @mwasilew as he is our lab admin and will generate on our behalf.

Many thanks!

[EmbeddedAndroid]

@JenySadadia we have generated the token and description, shall I email to you or is there another method you'd prefer?

A more generic question, is there documentation on how LAVA jobs are generated with the new infra? We are trying to get our heads around if we need to do this now, or it will be provided by the KCI project.

[pawiecz]

@EmbeddedAndroid I can't point you to the docs but let me give you a quick overview:

Templates for submitted LAVA TestJobs are currently split between two repos (to be merged in the future):

1. https://github.com/kernelci/kernelci-pipeline/tree/main/config/runtime
2. https://github.com/kernelci/kernelci-core/tree/main/config/runtime

Former ones in many cases (baseline, kselftest, sleep, tast) set up values for rendering final TestJob definitions, latter ones contain LAVA-specific sections.

Basic example (baseline-arm64):

1. Scheduler entry sets trigger conditions (successful kernel build), runtime (which lab will run jobs) and platforms (device types)
2. Corresponding job (which uses a baseline.jinja2 template to set up required values) will be triggered
3. From a job template ^ proper LAVA TestJob will be rendered: extending runtime base template with (platform-specific) boot_method and test steps templates

Here is a node example of such a job with corresponding LAVA TestJob

[mwasilew]

@pawiecz Do I understand correctly you will still be submitting jobs to the LABs (push)? I was under impression the new architecture asks labs to pull the events and submit the jobs themselves.

[padovan]

@mwasilew you can do both. See #349 (comment) for the pull example.

[pawiecz]

@mwasilew to complete the picture: TestJobs are pushed to the LAVA instances and the event activation (pulling) is used internally by sub-services.

[mwasilew]

@pawiecz ok, so there is no difference comparing to the "old way". There is still no way to enroll with lava server behind firewall.

[JenySadadia]

@JenySadadia we have generated the token and description, shall I email to you or is there another method you'd prefer?

Hi, you can send me on IRC. My nickname is jenysadadia. Thanks.

[pawiecz]

@mwasilew short follow-up about verifying if LAVA TestJob templates render expected definitions:
after setting up core environment and moving all templates (including config/runtime/* from -pipeline repo) into -core's config/runtime you can use the existing Node to rerender TestJob definitions.

Example:

1. Using staging Node 6653735bce5c0068e1b06921
2. Edit the templates in config/runtime
3. Call ./kci job generate -c ../kernelci-pipeline/config/pipeline.yaml --runtime=lava-collabora 6653735bce5c0068e1b06921 to render definitions