action #1316
closedA general manual configuration file
50%
Description
(Original Author: Yifan Jiang)
Most part of this is based on Makefile.pm::iso_new, 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"
ISO="path/sled12-gnome-live.iso"
DESKTOP="GNOME"
LVM='1'
NICEVIDEO='1'
...
KVM_PARA="-m 1024 -net user -vga cirrus..."
Job "SLED 12 KDE"
ISO="path/sled12.iso"
DESKTOP="KDE"
LVM='0'
NICEVIDEO='1'
...
KVM_PARA="-m 1024 -net user -vga cirrus..."
--------------------><--------------------
Noticeably the KVM_PARA here is a frequently revised key from 'startqemu.pm', 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.
Updated by yfjiang almost 11 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 :)
Updated by lnussel almost 11 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.
Updated by lnussel almost 11 years ago
Suggestion:
- 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/*/openqa.pm
Updated by lnussel almost 11 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.
Updated by lnussel almost 11 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
Updated by lnussel almost 11 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.
Updated by coolo almost 10 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"
Updated by okurz almost 9 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?
Updated by okurz over 5 years ago
- Category changed from 132 to Feature requests
Updated by okurz about 5 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 :)