QA » openQA Project

some additional ideas since yesterday:

mmapi tries to schedule jobs, it fails, the test tries again after some time
alternative to this: scheduling jobs will never fail, the jobs will appear as "scheduled", scheduler decides when to run them.

Scheduler starts the parallel test groups one after another, the situation when multiple groups are partially started can't happen and thus it is not handled currently.
The problem with parsing node file is that the job that parses it and creates other jobs is part of a group, but the scheduler does not know it from the beginning.
Options:

1 Improve scheduler to handle the situation when the first job from each group is already running and start the remaining jobs one group after another. This leads to the limitation number(slenkins tests) = number(available nodes with slenkins worker class) - max(possible children).

2 Make the job that parses the node file independent of the jobs it creates. All node files can be actually parsed in one job. This is compatible with current scheduler.

3 Number(slenkins tests) = number(available nodes with slenkins worker class) / max(possible children)

• this is most conservative limitation, no deadlock is possible
• wastes resources, unless there is enough single-machine jobs to run on the remaining workers example: 20 workers, max 8 children per test, typically 3, number of slenkins tests = 2, typical load 2 * 3 = 6 workers of 20

In any case, the jobs in a group should be created atomically, current api does not allow this. I think that clone_job.pl also suffers from this problem.
Options:

• create multiple jobs in one api call
• introduce new status "prepared", create jobs with this status, add api call to atomically switch whole group from prepared to scheduled

is this done? can you say what is the status on this one?

"Epic" is a good category here :-)

Jokes aside: @okurz: is this still valid ticket? we do not run SLEnkins test in openQA, right? Or am I miss something?
"The use case are mainly slenkins control nodes"

Am I correct that in the meantime some of the ideas got implemented?

I would be quite interested in refining this ticket in technical details and see what we could do about it, as we both agree (I assume) mm tests could benefit from some enhancements or perhaps there could be completely new take on them where we would end up with another way of doing mm test in openQA?

See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html