Bug 1437598

Summary: After down the bridge, it's not possible start bridge + slaves at once
Product: Red Hat Enterprise Linux 7 Reporter: Waldirio M Pinheiro <wpinheir>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.3CC: aloughla, atragler, bgalvani, fgiudici, lrintel, rkhan, sukulkar, thaller, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 13:22:08 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1470965    
Attachments:
Description Flags
[PATCH 1/2] device: make nm_device_state_reason_to_str() public
none
[PATCH 2/2] core: allow slaves to autoactivate when master is available none

Description Waldirio M Pinheiro 2017-03-30 15:45:13 UTC
Description of problem:
After configure the bridge, when we stop the bridge via cli or UI and just start, the connection didn't come up again.

Version-Release number of selected component (if applicable):
RHEL 7.3

How reproducible:
100%

Steps to Reproduce:
1. down the bridge (nmcli c down BridgeWall)
2. start the bridge (nmcli c up BridgeWall)
3.

Actual results:
Slave still disconnected

Expected results:
Start everything, once I'm using the UI to do this management, I don't have any option to start the slave.

Additional info:

Comment 2 Waldirio M Pinheiro 2017-03-30 15:47:18 UTC
Hi

Below some changes that I did on my environment and then the environment is working fine.

---
[root@dvader ~]# nmcli c edit BridgeWall
nmcli> print
nmcli> set connection.autoconnect-slaves 1
nmcli> set bridge.forward-delay 2
nmcli> set bridge.hello-time 1
nmcli> save persistent 
nmcli> quit
# nmcli c down BridgeWall
# nmcli c up BridgeWall
---

The most important point here was *set connection.autoconnect-slaves 1* but I believe be one good approach define all values above as default in our RHEL 7.3


Best Regards
-- 
Waldirio M Pinheiro | Senior Software Maintenance Engineer

Comment 3 Vladimir Benes 2017-03-30 16:52:58 UTC
Yeah, sadly this is not possible now. In nmcli or nmtui you can up slave to up master too, or as you've pointed out upping master with connection.autoconnect-slaves 1 works as well.

What I see we should have is:
1. possibility to set connection.autoconnect-slaves 1 in nm-connection-editor (and nmtui)
2. possibility to up a connection in nm-connection-editor
(not sure if those RFEs aren't filed already)

There are no options to up bridge slaves in control-center or GNOME Shell and all advanced networking is going to be removed from control-center in the future so we definitely need to add those options to nm-connection-editor for future NM releases.

Comment 4 Lubomir Rintel 2017-05-09 14:49:02 UTC
I think that if the slaves are connection.autoconnect=1 (note: this should be the default, unlike connection.autoconnect-slaves=1 on the master), the slaves should come up automatically.

I need to look into this.

Comment 5 Beniamino Galvani 2017-11-10 13:01:05 UTC
Created attachment 1350463 [details]
[PATCH 1/2] device: make nm_device_state_reason_to_str() public

Comment 6 Beniamino Galvani 2017-11-10 13:01:41 UTC
Created attachment 1350464 [details]
[PATCH 2/2] core: allow slaves to autoactivate when master is  available

Comment 7 Beniamino Galvani 2017-11-10 13:04:38 UTC
I think slaves should be able to autoconnect when they have con.autoconnect=yes and the master becomes available, unless the connection/device is blocked because the user explicitly disconnected it.

Comment 8 Thomas Haller 2017-11-13 11:04:20 UTC
lgtm

Comment 13 errata-xmlrpc 2018-04-10 13:22:08 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-2018:0778