Re: KCIDB contribuition #KCIDB

["Santiago.Esteban via info" <santiago.esteban@microchip.com>]

On 22/2/21 11:25, Guillaume Tucker wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 22/02/2021 09:41, Nikolai Kondrashov wrote:
>> Hello Santiago,
>>
>> On 2/22/21 10:02 AM, Santiago.Esteban via info via groups.io wrote:
>>> Good morning KernelCI, Nikolai,
>>>
>>> As I mention here before, I work at Microchip, and we are building a
>>> test farm based on Labgrid which currently, allow us to test Linux
>>> kernels in several ARM SoC devices (Cortex-A5, ARM9 variants). We would
>>> like to contribute to KernelCI effort with our builds/tests but support
>>> for non Lava external labs is not available yet.
>>>
>>> Therefore, It seems that KCIDB is the place for us. We would like to
>>> start contributing our builds/tests to this project.
>>>
>>> As part of our current efforts, we have build a local instance of the
>>> KernelCI infrastructure. I've already asked Nicolai @DevConf, but here,
>>> at a wider audience, Are there any tool that allows to submmit
>>> "standard" KernelCI formatted data into the KCIDB database?
>> I suppose if you already drive everything with an instance of KernelCI
>> infrastructure, you can just use the KCIDB interface code that was merged
>> there. However, I think Guillaume would be able to help you better here.
>>
>> Guillaume, do you think that would work?
> The production instance of kernelci.org is not submitting data to
> KCIDB yet because of the overhead related to opening BigQuery
> connections.  Until the work to use the streaming interface with
> a persistent connection is implemented, and potentially a more
> longer-term implementation is in place (i.e. not doing it in
> kernelci-backend), I would not recommend doing that.
>
> However, if you are available to help it would be great to speed
> up the work with redesigning kernelci-backend.  It should have
> happened about a year ago but there have been many distractions
> on the way slowing things down.  It's becoming the main sticking
> point now, so it will soon be receiving the attention it
> deserves.
>
> One thing I don't quite get, is that if you already have an
> instance of KernelCI driving your test lab, why not have your
> test lab connected to the kernelci.org instance in the same way?
> Having Labgrid properly supported by KernelCI is still on the
> roadmap, in fact it's related to the redesign of
> kernelci-backend.
> Having your own CI pipeline is mostly useful if you want to build
> your own kernels or run tests in a private environment.  All the
> current KCIDB contributions are coming from preexisting CI
> systems which do just that (distro kernels, private test labs).
> But if you want to use the builds from kernelci.org and do what
> all the other labs on kernelci.org already do, then using KCIDB
> directly doesn't seem like the logical choice to me (and results
> going to kernelci.org will also end up in KCIDB).

Currently, we build linux-mainline and linux-next along with our 
repositories linux4sam (https://github.com/linux4sam). We also use our 
Labgrid farm to tests embedded distributions (Buildroot, Yocto and 
Openwrt). Soon (I hope), we will include more test for other parts of 
our software stack (u-boot, at91bootstrap) and other hardware tests in 
our devices/platforms. Our farm contains 7 different boards today, and 
it will keep growing.

If all results from KernelCI will end up also in KCIDB (this was not 
clear to me), obviously, it does not make sense push my tests in both 
databases.  As you know, we can push test results to staging (I'm not 
allowed to push my builds), but we do not have means to get notified 
when a new builds are available for testing.  That's what is missing 
(for Labgrid or other external lab). While we work in this front, I 
understood, from Nikolai's last week presentation, that it would be nice 
to push also our result to KCIDB too (and it would be fairly easy). 
Anyway, for me it is clear now, that connecting my farm to KernelCI is 
key, and as a bonus, we'll get KCIDB :-).

>
> Best wishes,
> Guillaume

BR,

Santi