action #12876

action #32851: [tools][EPIC] Scheduling redesign

[epic] Offer a way for jobs to schedule children

Added by coolo over 3 years ago. Updated 8 months ago.

Status:NewStart date:05/05/2018
Priority:LowDue date:
Assignee:-% Done:

0%

Category:Feature requests
Target version:Ready
Difficulty:
Duration:

Description

As discussed with Vladimir, we want to offer an API in mmapi for tests to schedule children. The use case are mainly slenkins control nodes, but we can also use it to ease dynamic tests.

The use case is:
slenkins-nfs-control starts and installs the slenkins package into the VM.

The test then figures from the given control file that it needs a nfs-server and a nfs-client with a
given set of settings (currently implemented in the slenkins-import script).

It asks mmapi to schedule two tests as children following its own settings, but with a set of new variables (each).

If mmapi refuses to schedule them, the test waits and retries in a couple of minutes.

If the jobs are scheduled, we get to the normal mmapi function to wait for the children to boot before we call into slenkins.

openQA in return will schedule the children jobs with a high priority (to avoid dead locks), but will refuse to create
any jobs if there are still scheduled jobs with that high priority (or some other means to check other children are taken).

And we need to make sure the slenkins tests are only run on a very limited amount of workers - as they fork children basically
the formula is number(slenkins tests) = number(available nodes with slenkins worker class) - max(possible children). Otherwise
we can create a deadlock.

The benefit is that slenkins tests don't require manual mantenance anymore, but only once registration.

History

#1 Updated by nadvornik over 3 years ago

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

#2 Updated by okurz about 3 years ago

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

#3 Updated by coolo over 2 years ago

  • Subject changed from Offer a way for jobs to schedule children to [epic] Offer a way for jobs to schedule children
  • Status changed from In Progress to New
  • Assignee deleted (nadvornik)
  • Priority changed from Normal to Low
  • Target version set to Ready

This is still very much wanted for more comfort in multi machine tests.

#4 Updated by EDiGiacinto almost 2 years ago

  • Parent task set to #32851

Setting it as part of the scheduling enhancement ticket

#5 Updated by szarate almost 2 years ago

  • Start date changed from 26/07/2016 to 05/05/2018

due to changes in a related task

#6 Updated by okurz 8 months ago

  • Category changed from 122 to Feature requests

Also available in: Atom PDF