Bug 1327646

Summary: Device name under host details -> NIC tab for alias interface is incorrect on registering host via puppet
Product: Red Hat Satellite Reporter: Sachin Ghai <sghai>
Component: FactAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WONTFIX QA Contact: Sachin Ghai <sghai>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: inecas, mhulan, tstrachota
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
URL: http://projects.theforeman.org/issues/7470
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-04 18:04:55 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:
Attachments:
Description Flags
alias interface name appears as enp6s0.0 instead of enp6s0:0 none

Description Sachin Ghai 2016-04-15 14:27:12 UTC
Created attachment 1147676 [details]
alias interface name appears as enp6s0.0 instead of enp6s0:0

Description of problem: I added alias and vlan interface and bridge interface on a pre-installed host, later I registered it via puppet. All interface shown correctly under all hosts -> details-> NIC tab. However interface name of alias is shown as "enp6s0.0" and it was defined as enp6s0:0 in config file.


enp6s0:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.127  netmask 255.255.255.248  broadcast 192.168.100.127
        ether 34:40:b5:8f:b4:06  txqueuelen 1000  (Ethernet)
        device interrupt 17  memory 0xc1a80000-c1aa0000  

enp6s0.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.126  netmask 255.255.255.248  broadcast 192.168.100.127
        inet6 fe80::3640:b5ff:fe8f:b406  prefixlen 64  scopeid 0x20<link>
        ether 34:40:b5:8f:b4:06  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 732 (732.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@cloud-qe-19 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp6s0_0 
BOOTPROTO="none"
IPADDR="192.168.100.127"
NETMASK="255.255.255.248"
GATEWAY="192.168.100.1"
DEVICE=enp6s0:0
ONBOOT=yes
PEERDNS=no
PEERROUTES=no
TYPE=Alias


Please see screenshot of webUI, where alias interface name appears as enp6s0.0

Version-Release number of selected component (if applicable):
sat6.2 beta snap8.1

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:
when we register host via puppet device name under host details -> NIC tab for alias interface is incorrect. It appears as enp6s0.0 instead of enp6s0:0

Expected results:
in webUI alias interface name appears as what is in config file or shown on console.

Additional info:

Comment 3 Ivan Necas 2016-04-20 15:47:05 UTC
AFAIK the problem was with facter not handling the naming properly: I'm sure mhulan knows the whole story behing it and if it's even feasible to fix.

Comment 4 Marek Hulan 2016-04-21 06:38:30 UTC
The limitation of facter is that it converts both eth0:1 end eth0.1 to fact with the same name - ipaddress_eth0_1. Therefore we can't really decide on server, what type of interface it is. So when we can't decide we guess that it's VLAN interface since IMHO it's more common. In a specific case where suffix is 0 we could say it's Alias since VLAN tag can't be 0 IIRC. But that would solve it just for one case.

We could check if there's an interface with the same name just . instead of : and match it in such case but there would still remain the issue when there is eth0:1 and eth0.1 at the same time. In this case, facter overrides facts and we can't even say which data we get.

Btw this is already reported as http://projects.theforeman.org/issues/7470 I'll do the linking.

Comment 6 Bryan Kearney 2016-04-21 14:04:50 UTC
Upstream bug component is Fact

Comment 7 Bryan Kearney 2018-09-04 18:04:55 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.