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
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.
- 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
- 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).
The following implementation idea is just theory. This approach would involve the following steps:
- Add the new dependency type
- Extend the code which inserts new dependencies into the database from job settings
- Extend cancellation and error handling to take the new dependency type into account
- Let the scheduler take the new dependency type into account
- 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
- Support tracking multiple jobs per worker at the same time on the web UI side
- Make use of the already existing relation in the database (which is currently only used for the worker's job history)
- Possibly remove the now redundant worker-job relation
- Allow the web socket server to pass multiple jobs to the worker at the same time
- 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.
- 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'.