Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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.
Bug 1743432 - NICs facts are not interpolated correctly after registration
Summary: NICs facts are not interpolated correctly after registration
Keywords:
Status: CLOSED DUPLICATE of bug 1528193
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscription Management
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Cole Higgins
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-20 00:05 UTC by matt jia
Modified: 2023-10-06 18:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-25 07:59:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description matt jia 2019-08-20 00:05:13 UTC 
Description of problem:

Given a host that is using a tagged/bonded network, after being registered to Satellite, Satellite doesn't interpolate the facts correctly to make the NICs correct in the host info.

Version-Release number of selected component (if applicable):

6.4

How reproducible:

Easy


Steps to Reproduce:
1. build a host with a tagged/bonded network
2. register the host to Satellite
3. check the network interfaces of the host in Satellite 

Actual results:

The NICs don't match the ones configured on the host

Expected results:

The NICs should match the ones on the host

Additional info:

No puppet is configured on the host. The output of `subscription-manager facts` is:

---
...
net.interface.bond0.3551.ipv4_address: 10.22.148.26
net.interface.bond0.3551.ipv4_address_list: 10.22.148.26
net.interface.bond0.3551.ipv4_broadcast: 10.22.151.255
net.interface.bond0.3551.ipv4_broadcast_list: 10.22.151.255
net.interface.bond0.3551.ipv4_netmask: 22
net.interface.bond0.3551.ipv4_netmask_list: 22
net.interface.bond0.3551.mac_address: D0:43:1E:62:6F:28
net.interface.bond0.mac_address: D0:43:1E:62:6F:28
net.interface.em1.mac_address: D0:43:1E:62:6F:28
net.interface.em1.permanent_mac_address: D0:43:1E:62:6F:28
net.interface.em2.mac_address: D0:43:1E:62:6F:2B
net.interface.em3.mac_address: D0:43:1E:62:71:FA
net.interface.em4.mac_address: D0:43:1E:62:71:FD
net.interface.em5.mac_address: D0:43:1E:62:6F:90
net.interface.em6.mac_address: D0:43:1E:62:6F:28
net.interface.em6.permanent_mac_address: D0:43:1E:62:6F:93
net.interface.em7.mac_address: D0:43:1E:62:77:B2
net.interface.em8.mac_address: D0:43:1E:62:77:B5
net.interface.lo.ipv4_address: 127.0.0.1
net.interface.lo.ipv4_address_list: 127.0.0.1
net.interface.lo.ipv4_broadcast: Unknown
net.interface.lo.ipv4_broadcast_list: Unknown
net.interface.lo.ipv4_netmask: 8
net.interface.lo.ipv4_netmask_list: 8
...
---

The hammer output is:
---
Network interfaces:       
 1) Id:          680
    Identifier:  bond0
    Type:        bond
    MAC address: d0:43:1e:62:6f:28
    FQDN:
 2) Id:          675
    Identifier:  em2
    Type:        interface
    MAC address: d0:43:1e:62:6f:2b
    FQDN:
 3) Id:          677
    Identifier:  em3
    Type:        interface
    MAC address: d0:43:1e:62:71:fa
    FQDN:
 4) Id:          676
    Identifier:  em4
    Type:        interface
    MAC address: d0:43:1e:62:71:fd
    FQDN:
 5) Id:          674
    Identifier:  em5
    Type:        interface
    MAC address: d0:43:1e:62:6f:90
    FQDN:
 6) Id:          673
    Identifier:  em6
    Type:        interface (primary, provision)
    MAC address: d0:43:1e:62:6f:28
    FQDN:        usmtnz-linfra02.dev.emrsn.org
 7) Id:          679
    Identifier:  em7
    Type:        interface
    MAC address: d0:43:1e:62:77:b2
    FQDN:
 8) Id:          678
    Identifier:  em8
    Type:        interface
    MAC address: d0:43:1e:62:77:b5
    FQDN:
---

In reality, the primary interface should be bond0.3551. em6 is just a slave of it.
Comment 5 Marek Hulan 2019-09-05 14:00:07 UTC 
Moving as this is a RhsmFactImporter issue, not sure what is the best component for it.
Comment 6 Peter Vreman 2019-11-04 16:30:05 UTC 
The root cause is that em1 is missing and em6 has a wrong MAC (duplicate of em1). This matches 100% BZ https://bugzilla.redhat.com/show_bug.cgi?id=1528193
Comment 7 Peter Vreman 2019-11-04 16:31:29 UTC 
Forgot to mention https://bugzilla.redhat.com/show_bug.cgi?id=1528193#c4 contains a Patch for this
Comment 10 Marek Hulan 2020-03-25 07:59:06 UTC 
Thanks Peter, the linked issue is expected to be fixed in an upcoming 6.7 release and looking at the code, it seems it should help in this case too. Matt can you please confirm with the customer once 6.7 is out and they upgrade to this version? I'm closing this for now as a duplicate, however if there's something not addressed by BZ 1528193, please reopen.

*** This bug has been marked as a duplicate of bug 1528193 ***
Note You need to log in before you can comment on or make changes to this bug.