action #32296
closedopenvswitch salt receipe is 'unstable'
100%
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
Updated by thehejik almost 7 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).
Updated by thehejik almost 7 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.
Updated by thehejik almost 7 years ago
- Related to action #31978: Multimachine configuration is busted for aarch64 added
Updated by thehejik over 6 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.
Updated by asmorodskyi over 6 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
Updated by thehejik over 6 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
Updated by okurz over 5 years ago
- Project changed from openQA Project (public) to openQA Infrastructure (public)
Updated by thehejik over 5 years ago
- Status changed from In Progress to Resolved
I think this was solved as well, please reopen if not. Closing.
https://gitlab.suse.de/openqa/salt-states-openqa/commit/9d373d4ad49dab696afd620f30a9fe4aac0930aa