Use v2 Code Of kerneltest Application

There is already a work in progress rewrite of kerneltest application started by Jeremy Cline, which was never finished. This document is investigating if this option is feasible and we should continue on the code already written. From meeting with Justin Forbes this code is not 100% ready, which is the reason it was never been released.

What is in v2

  • Some unit tests in kerneltest/tests (not covering everything, but at least part of the code is covered) run by tox - failing with never version of libraries

  • API calls for /api/v1/results

    • GET method to retrieve tests information

    • POST method to add new test run to db (authentication scopes doesn’t seem to be set correctly)

    • Sending Fedora message when adding a new test run

  • Basic OIDC implementation using flask_oidc library

  • Configuration file loading and defaults

  • Forms for updating/creating release and submitting logs are in place

  • Web routes implemented

    • /index

    • /login

    • /logout

    • /release/<release> - information about specific fedora release

    • /kernel/<kernel> - information about specific kernel version

    • /results/<test_run_id> - information about specific test

    • /upload - test result uploading

    • /stats

    • /admin/new - add new release (does emit fedora message)

    • /admin/<release>/edit - edit existing release (does emit fedora message)

  • DB models for Test, TestRun and Release

What is missing in v2

  • Documentation

  • No support for uploading logs yet

  • Web interface revitalization

  • Code itself more than 3 years old, there could be some issue with newer libraries


  • There is a kerneltest/ source file in the v2. This could be ignored as it’s maintained separately and isn’t part of the kerneltest application.

  • The Vagrantfile introduced with v2 rewrite doesn’t start with vagrant 2.2.19, see

  • Ansible for vagrant provisioning is missing installation of some packages for database creation (python-alembic, python-toml)

  • Ansible for vagrant provisioning doesn’t create config file. Because of this creation of the database fails

  • The current state of v2 can’t be even started, failing on newer version of wtforms library

The Good Points

  1. Not starting from scratch = less work

The Bad points

  1. Make familiar with existing code = more time needed

  2. Data migration will be difficult, because the db schema is too different from 1.2