Bug 1543557

Summary: reconnect of ovs components should work flawlessly
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: NetworkManagerAssignee: Lubomir Rintel <lrintel>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: low Docs Contact:
Priority: low    
Version: 7.5CC: atragler, bgalvani, fgiudici, jmaxwell, lrintel, rkhan, sukulkar, thaller
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.18.0-0.3.20190408git43d9187c14.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 13:16:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1654714    

Description Vladimir Benes 2018-02-08 17:46:41 UTC
Description of problem:
Now just devices where system devices can be reconnected w/o total breakage. This includes bond port and it's slaves. Openvswitch bridge master, port with ovs-interface or interface itself cannot be reconnected. It leads to broken configuration if only one piece is reconnected. This should be improved. 

Version-Release number of selected component (if applicable):
1.10.2 (but also 1.10.5)

How reproducible:
always

Steps to Reproduce:
1. https://github.com/NetworkManager/NetworkManager-ci/blob/master/nmcli/features/ovs.feature#L216

Actual results:
ovs-bridge0, ovs-port0 and ovs-iface0 cannot be reconnected ovs-bond0, ovs-eth3 and ovs-eth2 can be reconnected.

Expected results:
all should be reconnectable

Additional info:
ovs-iface is reconnectable but the first reconnect fails the second successed

Comment 4 Vladimir Benes 2019-04-01 09:11:17 UTC
nmcli conn add conn.type ovs-bridge conn.interface ovsbridge0 con-name ovs-bridge0
nmcli conn add conn.type ovs-port conn.interface port0 conn.master ovsbridge0 con-name ovs-port0
nmcli conn add conn.type ovs-port conn.interface bond0 conn.master ovsbridge0 con-name ovs-bond0
nmcli conn add type ethernet conn.interface eth2 conn.master bond0 slave-type ovs-port con-name ovs-eth2
nmcli conn add type ethernet conn.interface eth3 conn.master bond0 slave-type ovs-port con-name ovs-eth3
nmcli conn add conn.type ovs-interface conn.interface iface0 conn.master port0 con-name ovs-iface0

[root@gsm-r5s10-01 NetworkManager-ci]# nmcli device 
DEVICE      TYPE           STATE         CONNECTION  
eth0        ethernet       connected     testeth0    
iface0      ovs-interface  connected     ovs-iface0  
eth2        ethernet       connected     ovs-eth2    
eth3        ethernet       connected     ovs-eth3    
ovsbridge0  ovs-bridge     connected     ovs-bridge0 
bond0       ovs-port       connected     ovs-bond0   
port0       ovs-port       connected     ovs-port0   
eth1        ethernet       disconnected  --          
eth10       ethernet       disconnected  --          
eth4        ethernet       disconnected  --          
eth5        ethernet       disconnected  --          
eth6        ethernet       disconnected  --          
eth7        ethernet       disconnected  --          
eth8        ethernet       disconnected  --          
eth9        ethernet       disconnected  --          
lo          loopback       unmanaged     --  

then:
nmcli con up ovs-bridge0

and I have:
[root@gsm-r5s10-01 NetworkManager-ci]# nmcli c
NAME         UUID                                  TYPE           DEVICE     
testeth0     be8be67e-90ec-4a45-8049-58ad26ed0032  ethernet       eth0       
ovs-bond0    5424f6d2-6040-44de-9078-6ce0fa73c7c9  ovs-port       bond0      
ovs-bridge0  78c9ca6d-8b0b-43f7-94af-212ab1824dcb  ovs-bridge     ovsbridge0 
ovs-eth2     8c7e65a2-4c39-4410-8352-3f276cf6feae  ethernet       eth2       
ovs-eth3     ab2b6b62-fd2f-42a0-a29d-c9bd3f6fe0df  ethernet       eth3       
ovs-port0    a6b32950-520f-4364-841d-d8403466df38  ovs-port       port0      
ovs-iface0   dea60f36-09ad-4f55-8868-a2237b953715  ovs-interface  --         
testeth1     ba3e775d-7170-41b9-821a-fcf9711611ac  ethernet       --         
testeth10    72fd6fb1-6fc8-44dd-b871-9ade1bfb40ec  ethernet       --         
testeth2     14a15a94-c971-475c-a4ef-53cd87769ef9  ethernet       --         
testeth3     82ea5ace-fc25-4ea1-9e40-e5f534a1f11a  ethernet       --         
testeth4     631f3356-41fe-4007-9714-08a9fe85b472  ethernet       --         
testeth5     3d10ac18-8070-43e1-af34-0d1389a1fe1c  ethernet       --         
testeth6     73b2ae76-3d3f-43ea-afe0-4c5ceed62dff  ethernet       --         
testeth7     8028299f-a502-4a9f-a9fd-fd3479715a5a  ethernet       --         
testeth8     3310bf01-027b-4042-b836-0ab27a37b5c4  ethernet       --         
testeth9     c71cd27b-e43c-4253-ad5c-ac57154e14d3  ethernet       --  

iface0 is down.

Comment 5 Vladimir Benes 2019-04-09 13:59:16 UTC
working well now

Comment 7 errata-xmlrpc 2019-08-06 13:16:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2302