action #1316

A general manual configuration file

Added by aplanas over 7 years ago. Updated almost 2 years ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


(Original Author: Yifan Jiang)

Most part of this is based on, it is not seldom that we change part of the file when there is not in the existed entries taking care of a particular job creation. Relevant code snippet:

settings => {
'DESKTOP' => 'kde',
'HDDSIZEGB' => '20',
'BTRFS' => 1,

It could be more convenient to extract these items as a local configuration file, something like $HOME/.openqarc, containing some pseudo configuration like:

Section "JOBS"
Job "SLED 12 live"
KVM_PARA="-m 1024 -net user -vga cirrus..."

   Job "SLED 12 KDE"
       KVM_PARA="-m 1024 -net user -vga cirrus..."


Noticeably the KVM_PARA here is a frequently revised key from '', since in practice we may want to launch KVM with different parameters.

Hopefully the modified configuration could take effect without manually iso_delete/iso_new/restart worker, instead this may work directly to reflect every changes in the file:

$ systemctrl reload openqa

The above was the detailed things we expected in past practice. I understood it may need your overall consideration since there might be other concerns, or even more "configration" needs to take care by this proposed file. Nevertheless, I feel it still makes sense to spread the idea.

Related issues

Related to openQA Project - action #912: openqa: implement some smart prio distributionRejected


#1 Updated by yfjiang over 7 years ago

Thanks for putting it here, to be acknowledged, the request was originally from Xudong Zhang and Nick Wang. Yifan simply mereged the relevant stuff :)

#2 Updated by lnussel over 7 years ago

I doubt the logic can be expressed in a simple config file as there is code that adds snippets conditional.
What we could to is to refactor the code and have it in different files for sle, opensuse etc.

#3 Updated by lnussel over 7 years ago


  • have a base class with methods to parse isos and generate test runs
  • have os-autoinst distri packages provide those files, eg. in /var/lib/os-autoinst/tests/*/

#4 Updated by lnussel over 7 years ago

I think we should not do this yet. We need to define how the interaction with e.g. task#912 is. Ie how this 'whole iso' view resp transaction works. The iso_new function interacts with the schedule to e.g. remove old builds. Quite hackish but if we change this we need to find a better way first.

#5 Updated by lnussel over 7 years ago

  • Assignee set to lnussel
  • Target version set to Sprint 01
  • % Done changed from 0 to 30

as first step I'm splitting the code to have the iso parsing in separate files

#6 Updated by lnussel over 7 years ago

  • % Done changed from 30 to 50

I've separated the code. It's in www/cgi-bin/modules/openqa/distri/*.pm now. I'm considering that part of the task done for now. Maybe we should split it into other tasks.

#7 Updated by lnussel over 7 years ago

  • Target version deleted (Sprint 01)

#8 Updated by lnussel over 7 years ago

  • Assignee deleted (lnussel)

#9 Updated by coolo over 6 years ago

this request kind of outdated itself. But I think we still want a easier definition of job templates. The current dump is too "all or nothing"

#10 Updated by coolo over 6 years ago

  • Category set to 132

#11 Updated by okurz over 5 years ago

  • Subject changed from A general manual configration file to A general manual configuration file

Can someone rewrite the issue to be a more specific feature request or should we just consider it done and continue in existing more specific issues?

#12 Updated by okurz over 4 years ago

  • Target version set to future

#13 Updated by okurz about 3 years ago

  • Target version changed from future to future

#14 Updated by okurz about 2 years ago

  • Category changed from 132 to Feature requests

#15 Updated by okurz almost 2 years ago

  • Status changed from New to Resolved
  • Assignee set to okurz

As there was no response to my question from 3 years ago I guess we can close it now with no specific actions related to the request. I consider the vars.json as a "single configuration file" for running tests good enough and the structure within openQA for any segmentation on multiple levels as required sufficient. Moreover, with recent enablement of job templates using a YAML syntax one can even define variables in "one more place" but by simply not defining on the other places it might even fulfill the original request better :)

Also available in: Atom PDF