Project

General

Profile

Actions

action #54329

closed

24-worker-overall.t test assumes cpu_opmode capability will always be present, but it isn't

Added by AdamWill almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2019-07-16
Due date:
% Done:

0%

Estimated time:

Description

There's a subtest in 24-worker-overall.t:

my $capabilities      = $worker->capabilities;
my @capabilities_keys = sort keys %$capabilities;
is_deeply(
    \@capabilities_keys,
    [
        qw(
          cpu_arch cpu_modelname cpu_opmode host instance isotovideo_interface_version
          mem_max websocket_api_version worker_class
          )
    ],
    'capabilities contain expected information'
) or diag explain \@capabilities_keys;

that's assuming there will always be a cpu_opmode key in the capabilities hash. But...there won't. Here's the code that creates it, from lib/OpenQA/Worker.pm:

    open(my $LSCPU, "-|", "LC_ALL=C lscpu");
    for my $line (<$LSCPU>) {
        chomp $line;
        if ($line =~ m/Model name:\s+(.+)$/) {
            $caps->{cpu_modelname} = $1;
        }
        if ($line =~ m/Architecture:\s+(.+)$/) {
            $caps->{cpu_arch} = $1;
        }
        if ($line =~ m/CPU op-mode\(s\):\s+(.+)$/) {
            $caps->{cpu_opmode} = $1;
        }

so, we only get cpu_opmode if the lscpu output has "CPU op-mode(s): [something]" in it. But this is not always true. For a specific example, here's a ppc64 system I have access to:

[adamwill@openqa-ppc64le-01 ~][PROD]$ lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 80
On-line CPU(s) list: 0,8,16,24,32,40,48,56,64,72
Off-line CPU(s) list: 1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79
Thread(s) per core: 1
Core(s) per socket: 10
Socket(s): 1
NUMA node(s): 1
Model: 2.0 (pvr 004d 0200)
Model name: POWER8 (raw), altivec supported
CPU max MHz: 3491.0000
CPU min MHz: 2061.0000
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
NUMA node0 CPU(s): 0,8,16,24,32,40,48,56,64,72

This is a problem for Fedora because noarch packages (like openQA) can be built on any builder. If the package happens to get built on an ppc64 builder, this test fails and the build fails.

Not sure if the better fix for this is to assign cpu_opmode some empty value if no line is found, somehow infer a correct value, or just correct the test (and any other code that makes the same assumption?) to not assume it will be present.

Actions

Also available in: Atom PDF