Project

General

Profile

Actions

action #13972

closed

openqa scheduler can not schedule the multi-machine job with different "WORKER_CLASS" in same group

Added by jerrytang over 7 years ago. Updated about 7 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Support
Target version:
-
Start date:
2016-09-29
Due date:
% Done:

0%

Estimated time:

Description

I have 2 phy-machine with ipmi .
I need assign 2 ipmi-worker to 2 test-suites(jobs) with parallel dependence .

1 Setup 2 ipmi-workers with different WORKER_CLASS ,(specify the ipmi to the phy-machine)
2 Add 2 test(job) to same group with different "WORKER_CLASS";

When i trigger the job with parallel, the dependence job can not schedule.

After use same "WORKER_CLASS" , this issue is gone

Actions #1

Updated by jerrytang over 7 years ago

I think no one require 2 ipmi-phy-machines to perform the multi-machine job.
This block the virtualization migration test (which require 2 machines)

Actions #2

Updated by xlai over 7 years ago

  • Assignee set to coolo
Actions #3

Updated by xlai over 7 years ago

Clarify: Why need two different WORKER_CLASS?

For this dependency job group, one is source host, the other is destination host. The testsuite that needs to be run on the source host, needs to know the destination host ip. Only after scheduling, can we know which worker(IPMI_HOST) is the destination. mmapi has api to get parent job configurations. But the mmapi can neither get the static configurations of the worker(set in /etc/worker.ini), nor vars that are set dynamically after test starts. So we have no way to know the destination host ip via mmapi.
We figure our another way: bind source testsuite to worker with source_worker_class, and destination testsuite to worker with dest_worker_class in job group. So we can statically know the destination host information.

However from experiment result, when bind the two dependency jobs to the two different kinds of worker separately, trigger child job , only this child job is triggered, parent is not. But if bind the two jobs to the same worker class, either the dest_worker_class or source_worker_class, the chain(child and parent) can be triggered.

Actions #4

Updated by coolo over 7 years ago

  • Assignee changed from coolo to nadvornik
Actions #5

Updated by nadvornik over 7 years ago

I can't reproduce this.

Are you sure you have correct WORKER_CLASS on workers and jobs?

Actions #6

Updated by okurz over 7 years ago

  • Project changed from openQA Tests to openQA Project
Actions #7

Updated by okurz about 7 years ago

  • Category set to Feature requests
Actions #8

Updated by okurz about 7 years ago

  • Status changed from New to Rejected

no reaction from author

Actions #9

Updated by okurz about 7 years ago

  • Category changed from Feature requests to Support
Actions

Also available in: Atom PDF