Bug 1543557 - reconnect of ovs components should work flawlessly
Summary: reconnect of ovs components should work flawlessly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.5
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Lubomir Rintel
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1654714
TreeView+ depends on / blocked
 
Reported: 2018-02-08 17:46 UTC by Vladimir Benes
Modified: 2019-08-06 13:16 UTC (History)
8 users (show)

Fixed In Version: NetworkManager-1.18.0-0.3.20190408git43d9187c14.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 13:16:20 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2302 None None None 2019-08-06 13:16:36 UTC

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


Note You need to log in before you can comment on or make changes to this bug.