Bug 1589869

Summary: Network Manager does not manage OVS ports properly
Product: Red Hat Enterprise Linux 7 Reporter: Rajat Chopra <rchopra>
Component: NetworkManagerAssignee: Lubomir Rintel <lrintel>
Status: CLOSED CANTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.5CC: atragler, bgalvani, dsneddon, fgiudici, hjensas, lrintel, rkhan, sukulkar, thaller, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-06 17:16:13 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:

Description Rajat Chopra 2018-06-11 15:00:25 UTC
Description of problem:

 For VendorX openshift networking plugin workflow, it relies on ifcfg file to configure network interface on KVM/RHEL. It has been the case that NM_CONTROLLED is set to no, and the workflow works.

However for OpenShift on bare metal support, we need to have the interface be managed by NetworkManager. Since NM now supports OVS, for verification we tried to use sample ifcfg files for an OVS bridge and port similar to https://github.com/osrg/openvswitch/tree/master/rhel, and in addition set NM_CONTROLLED to yes. The effect we were seeing was however that the interface does not always gets managed by NM. In addition after the interface was up we also tried using nmcli to set managed to yes. The effect seemed to be the same.

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


How reproducible:
Always

Steps to Reproduce:

An example would be, to set up an OVS port on a bridge (sample ifcfg taken from https://github.com/osrg/openvswitch/tree/master/rhel, with NM_CONTROLLED set to yes):
==> ifcfg-eth0 <==
DEVICE=eth0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=ovsbridge0
BOOTPROTO=none
NM_CONTROLLED=yes

Actual results:
'nmcli d' shows that the interface is unmanaged

Expected results:
Network Manager should manage the said interface

Additional info:

Comment 2 Thomas Haller 2018-06-12 13:39:33 UTC
The way initscripts model OVS, correspond not directly to how OVS sees it. NetworkManager follows closer to OVS' model, and thus it is not compatible with initscripts'.

See `man nm-openvswitch` for examples.

Especially, you can not persist OVS connection profiles in ifcfg file format. Only keyfile format is supported (detailed in `man nm-settings-keyfile`). But commonly, you would not edit files directly, but use the D-Bus API (or one of the client tools, like nmcli).


The way to use NetworkManager is by first creating the suitable profiles ("connections").
Then, in a second step, activate the profile with `nmcli connection up "$PROFILE"`.

Comment 3 Rajat Chopra 2018-06-12 16:24:35 UTC
Can we make the initscript method work in some way? Can this bz become a request for enhancement?

Comment 4 Thomas Haller 2018-06-13 07:29:52 UTC
Theoretically possible, in practice probably not.

Can you elaborate on the value of that? How would you like to use that? It would be a larger effort, for something that does not seem like the right approach. 


If you choose to use NetworkManager instead of initscripts (which we think you should and which we would love to see!!), then you anyway would need to adjust your integration from using initscript to talking to NetworkManager. At that point, you preferably would no longer just dump ifcfg files, but talk NetworkManager API.
Dumping files is not the optimal way to use NetworkManager.

If you really just want to dump files, you can put them in keyfile format to /etc/NetworkManager/system-connections. See `man nm-settings-keyfile` for some details about the file format. Also, if you are interested in how the file would look like, a try+error approach seems helpful too. I mean: first use nmcli to configure the desired profile, and look how the generated profile looks in keyfile format. See examples in `man nm-openvswitch`.

Comment 5 Lubomir Rintel 2018-08-06 17:16:13 UTC
I'm closing this. It works as designed, that is, poorly.

Unfortunately there's not much we can do about keeping compatible with the poor design of openvswitch ifcfg files.