QA » openQA Project » openQA Tests

What?¶

Our isotovideo module currently has to handle 3 primary responsibilities: Machine/VM provisioning, test environment setup, test scheduling/execution.

This design creates a conflict of interest and makes the module itself harder to maintain.
It also makes changing parts of the backend much more difficult - if not straight up impossible - as the many functionalities of this module
are referenced in many other parts of os-autoinst.

Aside from this it also makes the codebase harder to understand for first time/outside contributors.

A possible solution would be to decouple the three main responsibilities of isotovideo into their own modules with each one having only one or two "public"
functions that are called by something on the outside. Everything else regarding this functionality should be handled internally.

For example:
Split isotovideo into a isotomachine module for machine/VM provisioning, testenv module for setting up a test environment and test_run module for the actual
test exeuction/scheduling/etc. All of these have only one function that a test_master module could call. test_master takes care of ensuring that each step is executed
at the right point in time, dispatching the other modules to do their thing, and handling any information or errors they may return and passing them on to the relevant
recipients.
Each module itself (isotomachine, testenv and test_runner respectively) would only be responsible for their defined roles not caring for or depending on the other modules.

An approach like this would help modularize os-autoinst and make it easier to change the way it operates without needing to tear too many links apart. It would also allow developers to completely swap modules for their own implementations as long as they provide this one public function that the test_master would call.

Goals¶

The goal of this change is to ease maintenance by decoupling and consolidating unrelated functionality into strictly separated modules which can easily be rewritten or replaced without major changes to the rest of the code.
As an additional benefit it would make the code be clearer and easier to understand for newcomers or outside contributors as the responsibility of each module is clear.