Generic lab support

[gctucker]

Automated test labs are a key part of KernelCI. The focus has been put mostly on LAVA until now, and it is still the preferred option when setting up new labs. However, there are many other types of labs with a lot of devices and test definitions written in a different format which could contribute to KernelCI.

One approach is to implement the kernelci.lab.LabAPI class to then add support for a new type of lab. This can be done in particular when the lab supports a remote API with a job definition format.

For more ad-hoc labs or if there is no publicly available API, a generic way of getting notifications for new tests to run and to send test results would make it possible to integrate them as much as possible.

• Generic subscription mechanism to get notified of new tests to run as a client
• Generic way to send test results using kci_data

[gctucker]

This is now part of the new API design with https://github.com/kernelci/kernelci-api.

[sestebanz]

Hi Guillaume, I have booted the new kernelci-api. It looks a very clean interface to start with. From the point of view of an external generic lab, it will have to listen events on a channel where kernel builds will be published and publish the corresponding test results on a different channel. Is this what you have in mind? BR, Santi On 23/10/21 0:27, Guillaume Tucker wrote: This is now part of the new API design with https://github.com/kernelci/kernelci-api. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#315 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOB7ULK7JE4R472VNHRYTWDUIHQNDANCNFSM4KPURH2Q>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[gctucker]

Hi Guillaume, I have booted the new kernelci-api. It looks a very clean interface to start with. From the point of view of an external generic lab, it will have to listen events on a channel where kernel builds will be published and publish the corresponding test results on a different channel. Is this what you have in mind?

Yes, absolutely. That is what the pub/sub mechanism will be for, clients can subscribe to receive events about some type of data. For example, you can receive events every time a kernel build is complete, with filters (e.g. CPU arch, defconfig...). Then you can send a query to retrieve the build details including URLs to the binaries etc. and run a test with it in your lab. And then you can push the results to the API, which will generate other events e.g. for another client in charge of detecting regressions or sending emails.

The pub/sub currently just passes on plain bits of text, but as soon as we start defining the database schema with test objects we can start generating events for when objects are added or updated.