action #32296
openvswitch 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
Subtasks
Related issues
History
#1
Updated by thehejik about 4 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).
#2
Updated by thehejik about 4 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.
#3
Updated by thehejik about 4 years ago
- Related to action #31978: Multimachine configuration is busted for aarch64 added
#4
Updated by thehejik about 4 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.
#5
Updated by asmorodskyi about 4 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
#6
Updated by thehejik about 4 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
#7
Updated by okurz almost 3 years ago
- Project changed from openQA Project to openQA Infrastructure
#8
Updated by thehejik almost 3 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