action #1316

A general manual configuration file

Added by aplanas about 6 years ago. Updated 7 months ago.

Status:ResolvedStart date:27/01/2014
Priority:NormalDue date:
Assignee:okurz% Done:

50%

Category:Feature requests
Target version:QA - future
Difficulty:
Duration:

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.


Related issues

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

History

#1 Updated by yfjiang about 6 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 about 6 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 about 6 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

#4 Updated by lnussel about 6 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 about 6 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 about 6 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 about 6 years ago

  • Target version deleted (Sprint 01)

#8 Updated by lnussel about 6 years ago

  • Assignee deleted (lnussel)

#9 Updated by coolo over 5 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 5 years ago

  • Category set to 132

#11 Updated by okurz about 4 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 3 years ago

  • Target version set to future

#13 Updated by okurz over 1 year ago

  • Target version changed from future to future

#14 Updated by okurz 8 months ago

  • Category changed from 132 to Feature requests

#15 Updated by okurz 7 months 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