action #55835

action #41066: Scheduling jobs for IPMI (bare metal) on the same worker (aka FOLLOW_TEST_DIRECTLY aka START_DIRECTLY_AFTER_TEST).

Support running multiple jobs directly in sequence on the same machine

Added by mkittler 6 months ago. Updated 5 months ago.

Status:ResolvedStart date:22/08/2019
Priority:NormalDue date:
Assignee:mkittler% Done:

0%

Category:Feature requests
Target version:Done
Difficulty:hard
Duration:

Description

User story

As a tester, I want to run multiple test job directly in sequence on the same machine, to test efficiently on bare metal SUTs and other self-provisioning environments.

Acceptance criteria

  • AC1: There is a way to specify that a job should run directly after another job on the same machine. E.g. add the test setting START_DIRECTLY_AFTER_TEST (in accordance to the already existing START_AFTER_TEST setting).
  • AC2: If one of the tests fails, subsequent tests in that dependency chain are aborted.
  • AC3: If one of the tests is cancelled while still scheduled, the entire job chain is cancelled.
  • AC4: The UI should show what's going on in a similar manner to what we already have for the other job dependencies.
  • AC5: Provide appropriate error handling for possible misconfigurations (e.g. jobs supposed to start directly after another have different worker classes).

Tasks

The following implementation idea is just theory. This approach would involve the following steps:

  1. Add the new dependency type
    1. Extend the code which inserts new dependencies into the database from job settings
    2. Extend cancellation and error handling to take the new dependency type into account
    3. Let the scheduler take the new dependency type into account
    4. Update all other places dealing with dependency types accordingly
      • e.g. the dependency graph possibly needs adjustments so that it at least does not show any misleading information
  2. Support tracking multiple jobs per worker at the same time on the web UI side
    1. Make use of the already existing relation in the database (which is currently only used for the worker's job history)
    2. Possibly remove the now redundant worker-job relation
  3. Allow the web socket server to pass multiple jobs to the worker at the same time
  4. Make the worker capable of accepting multiple jobs at the same time and run these in sequence without accepting another job in the meantime

Maybe it is worth to create sub-tickets or use to use the check list feature for the particular tasks.

The numbering is meant for easier referring but not to give a strict implementation order. Nevertheless it would make sense to start at least with the first task.

History

#1 Updated by mkittler 6 months ago

  • Description updated (diff)

#2 Updated by mkittler 6 months ago

  • Description updated (diff)

#4 Updated by pvorel 6 months ago

@mkittler: thanks for working on it!

#5 Updated by mkittler 6 months ago

  • Target version changed from Ready to Current Sprint

#6 Updated by mkittler 5 months ago

  • Status changed from New to In Progress

This is actually just a more concrete and technical version of the parent ticket. Since https://github.com/os-autoinst/openQA/pull/2309 is pretty far now I don't think it makes sense to create sub ticket. So I set it just to 'In Progress'.

#7 Updated by mkittler 5 months ago

  • Status changed from In Progress to Resolved

The PR implementing the ACs has been merged. I'm setting this ticket to resolved and the parent ticket to feedback.

#8 Updated by mkittler 5 months ago

  • Target version changed from Current Sprint to Done

Also available in: Atom PDF