Contribution: Renelick/VIXI alignment (Guillaume)

[bhcopeland]

Guillaume has been developing Renelick (general-purpose API and
automation framework) and VIXI (kernel testing application featuring
automated bisection), testing with builds and KUnit.

Need to figure out how this fits with the building blocks approach
here — is Renelick the foundation, do we pull common bits out, or
are they separate things that share interfaces?

Guillaume to chip in with feedback and tasks as things take shape.

[gctucker]

Thanks for creating this issue. There are a couple of typos:

• Renelick is the API and general-purpose automation framework
• VIXI is the application for kernel testing featuring automated bisection

See the first blog post to introduce them: https://gtucker.io/posts/2026-02-02-vixi-and-renelick/

The bisections can work with any kind of jobs running in VIXI i.e. builds, KUnit and boots in KVM for now.

There are different ways to apply this to KernelCI, I'll break this down into some comments here. Then if there's a consensus for a path forward I can help create issues etc. as a result.

[gctucker]

See #16 with a vixi.bisect snapshot to run it as a standalone tool. It still requires a Renelick API instance and all the relevant schedulers (e.g. Tekton) to replay the tasks.

[gctucker]

Before considering any path forward, here's a breakdown of the differences
between the Renelick/VIXI approach and KernelCI as it currently stands. The
first goal is to define the problem space and evaluate the efforts required to
reach a common solution from a high-level standpoint. Doing a more in-depth
analysis is likely to uncover many more challenges so this is only a starting
point before investing more efforts in any particular direction.

Renelick API

The Renelick API was forked from the new KernelCI API and while there are quite
a few differences, they are still about 60% similar. Renelick has the new
concept of Tasks which can translate to the scheduler queues used by KernelCI.
Nodes are read-only with Renelick so it should be quite straightforward to
adapt to the read-write approach in KernelCI although some assumptions about
data invariability would need to be revisited.

Tekton Runtime

The abstract runtime mechanism was already present in KernelCI before the fork.
There have been some changes e.g. scheduler handshake in Renelick but the
architectures remains comparable. As such, the VIXI bisection logic doesn't
have any knowledge about Tekton, LAVA, TuxMake or any tool in particular so
that should already provide a good starting point.

To add some context, most of the VIXI tasks (build, QEMU boot, KUnit) so far
are run in Tekton whereas KernelCI uses LAVA and TuxMake. It would be an
interesting exercise to see how well the abstraction handles those differences.

Data Schema

This is where things get a bit more tricky as the VIXI results are stored in
Renelick using a schema that is quite different from KernelCI. The bisection
logic relies solely on a subset of that schema which embeds some meta-data in
the results to enable replaying tasks and Delta nodes with regression data. At
least the issue should be fairly well defined. Making the logic work for
KernelCI would involve some substantial rework; I can see at least three
options:

1. rework KernelCI to follow the VIXI data schema (probably unrealistic)
2. add an adapter to convert KernelCI data to the VIXI schema on the fly
3. abstract away the schema in the bisection logic and let each system provide
   its own driver (seems ideal but may be impractical)

Orchestration

The bisection logic imported here as a standalone module is really part of the
VIXI application which does general task orchestration to produce the results
and run Delta jobs to find differences between them. In particular, the
"replay" feature is something that is part of the extended API client object
rather than the bisection module itself but is an essential component.

Some careful design decisions would need to be made in order to have a truly
reuseable toolbox without leaving too much as an "exercise for the reader" to
reimplement in each use case nor getting bloated with specific code. Having a
third use case in addition to KernelCI and Renelick/VIXI would help validate
the architecture in practice. Maybe this could be done with a neutral
reference implementation used for integrated testing in CI.

[bhcopeland]

Fantastic, thank you @gctucker!