Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
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"`.
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`.
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.