Project

General

Profile

Actions

action #14306

closed

It will resolve big trouble on multi-machine job if we can sync the variable set by set_var to the database which can query by get_job_info

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

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
-
Start date:
2016-10-19
Due date:
% Done:

0%

Estimated time:

Description

Here is the issue.
1.we perform a testsuite job require machines.

  1. machine 1 set_var(TARGET_VAR_1,"test").use mutex_lock to sync with machine2.
  2. machine use get get_job_info([machine's job_id) to get all variable and query the 'TARGET_VAR_1' .

the result is : we can NOT get the value.

I assume it not supported yet. so I open this request hope this can be implemented.

because once this feature done ,it will easy to communicate for the mutil-machine job, this will significant reduce the workaround code.

Actions #1

Updated by oholecek over 7 years ago

That is true, set_var does not sync variables back to openQA and I don't think we want it to. I see the variables in web ui as a job starting point (for reproducibility) and not the final state.

Actions #2

Updated by coolo over 7 years ago

if you need the machines to talk to each other - you better make that 1:1. There are enough tools to have 2 machines talking to each other

Actions #3

Updated by coolo over 7 years ago

but we can also add one within os-autoinst to tell PARALLEL_WITH jobs the os-autoinst URL of the other childrens and have a query_variables call into it.

Actions #4

Updated by jerrytang over 7 years ago

coolo wrote:

if you need the machines to talk to each other - you better make that 1:1. There are enough tools to have 2 machines talking to each other

Yes , I understand there are ways to make 2 host talking to each other.

The difficult part to the multi-machine parallel job is :
you can not know which host is assign as parent, which host is asseng as child .

(correct me if i miss something)

Actions #5

Updated by nadvornik over 7 years ago

There are at least these options:

  • you can use fixed set of IPs, assigned via variables

  • if you use DNS/DHCP on support server, the hostname included in DHCP requests is propagated to DNS and becomes resolvable on other hosts

Is there any reason why these options do not fit?

Actions #6

Updated by coolo over 7 years ago

because the initial request omited one small detail: this is not testing in VMs, but using real hardware in real networks with real DHCP servers. And we don't want to hard code upfront which machine gets which role in the test.

Actions #7

Updated by jerrytang over 7 years ago

yes , as coolo said , it's not running on virtualization machine in a isolate ENV.
For phy-machine : we may not have the permission to change the DHCP server.
we may not have the permission to modify the /etc/openq/openqa-worker.ini file

Actions #8

Updated by jerrytang over 7 years ago

Currently , the workaround is blocked by https://progress.opensuse.org/issues/13972

Beside fixed this issue , as above comment , we still need modify the /etc/openqa/worker.ini to distinguish ipmi worker each other.

Actions #9

Updated by nadvornik over 7 years ago

  • Assignee set to nadvornik

https://github.com/os-autoinst/os-autoinst/pull/631

This pull request hopefully implements the missing functionality.

Actions #10

Updated by jerrytang over 7 years ago

looks the set_var and save_var() work correctly sync the variable to the vars.json.

but still can NOT get the update setting from get_job_info($job_id) function in child job.

Actions #11

Updated by nadvornik over 7 years ago

get_job_info($job_id) still queries the openqa server so it can be used only for the initial variables.

Use get_job_autoinst_vars($job_id) instead (not sure if it is already deployed).

Actions #12

Updated by okurz over 7 years ago

  • Category set to Feature requests
Actions #13

Updated by okurz over 7 years ago

  • Status changed from New to Resolved

looks like resolved with #14306#note-9

Actions

Also available in: Atom PDF