Bug 1327646 - Device name under host details -> NIC tab for alias interface is incorrect on registering host via puppet
Summary: Device name under host details -> NIC tab for alias interface is incorrect on...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Fact
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Sachin Ghai
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-15 14:27 UTC by Sachin Ghai
Modified: 2021-12-10 14:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-04 18:04:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
alias interface name appears as enp6s0.0 instead of enp6s0:0 (35.53 KB, image/png)
2016-04-15 14:27 UTC, Sachin Ghai
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 7470 0 None None None 2016-04-22 16:45:01 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.