Bug 1065396

Summary:	ncftool list --all doesn't show interface, yet ncftool dumpxml works fine
Product:	[Fedora] Fedora	Reporter:	Cole Robinson <crobinso>
Component:	netcf	Assignee:	Laine Stump <laine>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	berrange, laine, mustafa1024m, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-14 09:23:12 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 Cole Robinson 2014-02-14 14:57:17 UTC

$ sudo ncftool dumpxml --live p14p1
<?xml version="1.0"?>
<interface name="p14p1" type="ethernet">
  <mac address="90:2b:34:66:3a:7e"/>
  <protocol family="ipv4">
    <ip address="192.168.1.149" prefix="24"/>
  </protocol>
  <protocol family="ipv6">
    <ip address="fe80::922b:34ff:fe66:3a7e" prefix="64"/>
  </protocol>
</interface>

$ sudo ncftool list --all
lo

Affects libvirt as well, which screws up some virt-manager validation as mentioned here:

https://bugzilla.redhat.com/show_bug.cgi?id=1065042

Comment 1 Laine Stump 2014-05-14 09:05:21 UTC

This is most likely due to the ifcfg file missing the DEVICE= line, which is required by netcf when it is creating its list of devices. The "name" of a network device can appear in at least three different places, and although they used to usually match, they don't have to match, and increasingly they do not match:

1) DEVICE attribute in ifcfg file
2) NAME attribute in ifcfg file
3) ifcfg filename (everything after "ifcfg-"

netcf checks (1) and (3), and requires them to match. It ignores 2. Based on recent practices in NetworkManager, this doesn't always work well, since NetworkManager (and anaconda) tend to no longer populate DEVICE, and very often have a different value in NAME and yet another in the ifcfg filename (and *both* of them are different from the actual name of the device). Also entering into this mix is the UUID, which NM people say is the only *real* persistent key to any network device (if I'm recalling my NM lore correctly).

In light of all this, I'm not really sure what course can/should be taken to arrive at something useful. Should netcf base the output of "ncftool list" on the list of interfaces returned from netlink rather than the contents of the config files? That seems of dubious merit, as the original intent of netcf was to simplify configuring network devices, and the list of devices returned by netlink includes many transient devices that have no persistent config.

Or, on the other hand, should we look at NAME if DEVICE isn't present? that seems likely to fail as well, because NAME is often set to something different from the device name, and also different from the ifcfg file name.

I would welcome any suggestions on how to resolve this mismatch of config paradigms in a reasonable and useful manner.

Comment 2 Laine Stump 2014-05-14 09:23:12 UTC


*** This bug has been marked as a duplicate of bug 911806 ***