QA (public) » openQA Project (public)

Acceptance criteria¶

• AC1: We know the best way to move forward with #169510.

Suggestions¶

• Bring https://github.com/os-autoinst/openQA/pull/6048 into a mergable state making the change configurable so we can try it out in production.
  • This has the benefit of going with a solution we (almost) already have in case it succeeds. It requires only a few changes in code.
• Move everything into one big transaction.
  • This requires some refactoring but it probably also not such a big deal. The only concern is that big transactions a generally disregarded.
    • Maybe not such a big concern as we only append rows to a few tables. So conflicts with other parallel transactions are unlikely.
    • Note that one probably needs to restart jobs in batches anyway to prevent timeouts (because also multiple smaller transactions accumulate in runtime). By using one big transaction it would at least be "all or nothing".
• Introduce a new initial job state (perhaps just called "new"). This is maybe the most future-proof solution.
  • See how far you can come within the timebox. There is a lot to do and it would be good to know how feasible/big the different tasks are:
    • Add a new constant and extend the relevant "meta state" as well.
    • Ensure proper state transitions in all relevant code (also in error cases), e.g. let a job transition from "new" to "scheduled" only if all Minion jobs are done (or if there were no Minion jobs created after all).
    • Let the scheduler not consider those jobs yet. (This is the whole point of the idea.)
    • Update the UI (controller code, HTML templates, CSS) and API (controller code, validation helpers) to correctly handle the new state where needed.
    • Update the Python library and potentially other tooling such as openqa-monitor as needed.

Maybe it makes most sense to give each top-level suggestion a try (moving on to the next suggestion after a certain amount of time was spent, even if not done yet).