action #32296: openvswitch salt receipe is 'unstable' - openQA Infrastructure - openSUSE Project Management Tool

Actions

Copy link

action #32296

closed

openvswitch salt receipe is 'unstable'

Added by coolo almost 6 years ago. Updated over 4 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

thehejik

Target version:

Start date:

2018-02-26

Due date:

% Done:

100%

Estimated time:

(Total: 0.00 h)

Description

The actual error/output changes, but there seems some inconsistency

Summary for openqaworker-arm-1.suse.de
--------------
Succeeded: 187 (changed=1)
Failed:      0
--------------
Total states run:     187
Total run time:     6.556 s
openqaworker-arm-2.suse.de:
----------
          ID: os-autoinst-openvswitch
    Function: service.running
      Result: False
     Comment: Service os-autoinst-openvswitch is already enabled, and is dead
     Started: 14:02:01.452509
    Duration: 971.109 ms
     Changes:   

Summary for openqaworker-arm-2.suse.de
--------------
Succeeded: 226
Failed:      1
--------------
Total states run:     227
Total run time:    10.661 s
openqaworker-arm-3.suse.de:
----------
          ID: os-autoinst-openvswitch
    Function: service.running
      Result: True
     Comment: Service os-autoinst-openvswitch is already enabled, and is running
     Started: 15:02:51.272510
    Duration: 838.534 ms
     Changes:   
              ----------
              os-autoinst-openvswitch:
                  True

Summary for openqaworker-arm-3.suse.de
--------------
Succeeded: 227 (changed=1)
Failed:      0
--------------
Total states run:     227
Total run time:    10.427 s
ERROR: Minions returned with non-zero exit code

Subtasks 2 (0 open — 2 closed)

Related issues 3 (0 open — 3 closed)

Actions

Copy link

Updated by thehejik almost 6 years ago

First we have to get openvswitch working on aarch64 - the service is probably failing because new aarch64 tap workers are not yet working properly due wicked/openvswitch/tap problems.

We have following problems with aarch64 workers:
1) on openqaworker-arm-1 openvswitch is running but we are unable to make br1 ovs interface up.
2) on openqaworker-arm-2 openvswitch is running, br1 is up but not all tap devices - we have only 20 tap devices but the worker needs 30x3=90 in total (30 workers x 3 possible networks).

Actions

Copy link

Updated by thehejik almost 6 years ago

Both problems 1) and 2) were solved by "systemctl restart wickedd" when those machines were already configured as mm workers.

I have a theory (I may be wrong) that restart of wickedd made the nanny service advertise again that br1 and tap* have a "fake" link and then it bring the interfaces up.

Actions

Copy link

Updated by thehejik almost 6 years ago

Related to action #31978: Multimachine configuration is busted for aarch64 added

Actions

Copy link

Updated by thehejik over 5 years ago

Status changed from New to In Progress

This issue should be solved by https://gitlab.suse.de/openqa/salt-states-openqa/merge_requests/34 where we do "wicked ifup br1; systemctl restart wickedd" to advertise that br1 has a "link" (nanny) and make it up.

Actions

Copy link

Updated by asmorodskyi over 5 years ago

Related to action #33841: [salt] Failed to run dbus command 'set_vlan' with arguments 'tap33 64' : 'tap33' is not connected to bridge 'br1' added

Actions

Copy link

Updated by thehejik over 5 years ago

Related to action #33253: [salt] add support for multiple multi-host worker clusters - connect multiple workers using GRE within the same WORKER_CLASS added

Actions

Copy link