Project

General

Profile

Actions

action #42569

closed

Unexpected error when setting QEMURAM is specified twice on workers.ini

Added by SLindoMansilla about 6 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2018-10-16
Due date:
% Done:

0%

Estimated time:

Description

Observation

Extracted from autoinst-log.txt

[2018-10-16T14:07:57.0185 CEST] [debug] QEMU: qemu-system-x86_64: -m '2048
[2018-10-16T14:07:57.0185 CEST] [debug] QEMU: 2048': Parameter 'size' expects a non-negative number below 2^64
[2018-10-16T14:07:57.0185 CEST] [debug] QEMU: Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta-
[2018-10-16T14:07:57.0185 CEST] [debug] QEMU: and exabytes, respectively.

Extracted from vars.json

QEMURAM: "2048 2048",

Content of /etc/openqa/workers.ini

[global]
HOST = http://slindomansilla-vm.qa.suse.de
WORKER_HOSTNAME=slindomansilla-vm.qa.suse.de
WORKER_CLASS = qemu_x86_64
QEMURAM = 2048
CACHEDIRECTORY = /var/lib/openqa/cache
QEMURAM = 2048

#[1]
#WORKER_CLASS = 64bit-ipmi

[http://slindomansilla-vm.qa.suse.de]
TESTPOOLSERVER = rsync://10.160.66.74/openqa-tests

Acceptance criteria

  • AC1: The INI parser detects the duplicate setting and explicitly complaints about it or, The last setting in global section overrides the value.

Suggestions

  • Check if duplicate settings can be prevented with a simple hash in openQA
Actions #1

Updated by SLindoMansilla about 6 years ago

  • Category set to Regressions/Crashes
Actions #2

Updated by coolo about 6 years ago

  • Subject changed from [tools] Unexpected error when setting QEMURAM is specified twice on workers.ini to Unexpected error when setting QEMURAM is specified twice on workers.ini
  • Priority changed from Normal to Low
  • Target version set to future

There is no such option in Config::IniFiles and I don't see any value in switching the perl module

Actions #3

Updated by okurz about 5 years ago

  • Description updated (diff)
  • Status changed from New to Resolved
  • Assignee set to okurz
  • Target version changed from future to Done

I believe 535f87443 fixed this.

I tested now by creating a duplicate entry in my /etc/openqa/workers.ini and could see the setting correctly applied for any job running on the server but only once so we are good.

Actions

Also available in: Atom PDF