Issue

Description of problem: When Teaming is configured on a physical host (with two physical interfaces (slaves)), "subscription-manager facts" is not able to identify the "permanent_mac_address" of the second slave interface. This happens because of a lack of support for Teaming on the python library /usr/lib64/python3.6/site-packages/rhsmlib/facts/hwprobe.py Since the "permanent_mac_address" property is set as "Unknown" for the second slave interface, an interface with and "empty" mac address is created/uploaded into Satellite 6. The follow problem is just a consequence of the one mentioned above: When puppet is executed on the host, it identifies the second slave interface and a MAC address and upload it into satellite, which is causing this interface to be duplicated in Satellite. This case the follow error on the Satellite Web UI: "Some of the interfaces are invalid. Please check the table below.". This also cause the follow error on the host when it tries to be subscribed into satellite: ________________________________________________________________________________________________________________________________________________ [ root@ my_host my_user]# subscription-manager register --org=xxx --activationkey="yyy" --force Unregistering from: myhostname:8443/rhsm The system with UUID 7a24cc2f-8ef3-4c01-a0d1-afbf4727f1b6 has been unregistered All local data removed HTTP error (422 - Unprocessable Entity): Validation failed: Interfaces some interfaces are invalid ________________________________________________________________________________________________________________________________________________ Please note that the issue here is the lack of support on "subscription-manager facts" for Teaming slave interfaces and not the duplication of interfaces on Satellite. The second is just a consequence of the first. Version-Release number of selected component (if applicable): This error has been identified both on RHEL7.9 and RHEL8.5 subscription management rules: 5.41 subscription-manager: 1.24.50-1.el7_9 and 1.28.21-5.el8_5 Red Hat Satellite build: 6.9.8 How reproducible: Set a Teaming interface with two slave interfaces on a physical host, then list the "subscription-manager facts" and validate that the second slave interface has an "Unknown" on the "permanent_mac_address" property (e.g. for a slave interface named "p4p2", net.interface.p4p2.permanent_mac_address: Unknown) Steps to Reproduce: 1. Set Teaming on a physical host with two slave interfaces and restart the network. ________________________________________________________________________________________________________________________________________________ [ root@ my_host my_user ]# cat /etc/sysconfig/network-scripts/ifcfg-team1 DEVICE="team1" DEVICETYPE="Team" BOOTPROTO="none" ONBOOT="yes" USERCTL="no" PEERDNS="no" PEERNTP="no" NM_CONTROLLED="no" IPADDR="10.20.30.40" NETMASK="255.255.255.0" GATEWAY="10.20.30.1" DEFROUTE="yes" TEAM_CONFIG='{"runner": {"name": "lacp", "active": true, "fast_rate": true, "tx_hash": ["ipv4", "ipv6", "tcp", "udp"]} , "link_watch": {"name": "ethtool"} , "ports": {"em1": {"prio": 100} , "p4p2": {"prio": 100} }}' ________________________________________________________________________________________________________________________________________________ 2. Execute "subscription-manager facts --list" and validate that the second slave interface has an "Unknown" on the "permanent_mac_address" property: ________________________________________________________________________________________________________________________________________________ [ root@ my_host my_user ]# subscription-manager facts --list| grep p4p2 net.interface.p4p2.mac_address: aa:bb:cc:dd:ee:ff net.interface.p4p2.permanent_mac_address: Unknown ________________________________________________________________________________________________________________________________________________ 3. Execute "subscription-manager facts --update" and validate that an interfaces with Identifier "p4p2" and an empty MAC Address was uploaded into Satellite. Actual results: Second Team slave interfaces uploaded into Satellite with an empty MAC Address. Expected results: Support on "subscription-manager facts" to support Teaming. For a detailed explanation of the root problem see "Additional info". Additional info: Host facts are gathered and uploaded into Satellite by the "subscription-manager" command. On RHEL 8.5 this command is provided by package subscription-manager-1.28.21-5.el8_5.x86_64, which provide the library responsible for gathering the information about the network interfaces (/usr/lib64/python3.6/site-packages/rhsmlib/facts/hwprobe.py). On lib hwprobe.py, the class "HardwareCollector" is defined, which contains the class methods (functions) "get_network_info" and "_get_slave_hwaddr". The property "permanent_mac_addr" is assigned on "get_network_info" method, by calling method "_get_slave_hwaddr", which only has support for bonding interfaces and not teaming: ________________________________________________________________________________________________________________________________________________ def _get_slave_hwaddr(self, master, slave): hwaddr = "" try: bonding = open('/proc/net/bonding/%s' % master, "r") except: return hwaddr slave_found = False for line in bonding.readlines(): if slave_found and line.find("Permanent HW addr: ") != -1: hwaddr = line.split()[3].upper() break if line.find("Slave Interface: ") != -1: ifname = line.split()[2] if ifname == slave: slave_found = True bonding.close() return hwaddr ________________________________________________________________________________________________________________________________________________ Since /proc/net/bonding/ does not exist for Teaming interfaces, this is causing the method "_get_slave_hwaddr" to return hwaddr = "". In the terminal, the "permanent"/"physical" MAC address can be show with the command "ethtool -P device_name". However, this information would need to be get in python.

Release Notes

No. of Comments

Resolution

Obsolete