Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionVladimir Dulava
2016-09-07 12:00:35 UTC
Description of problem:
Network interfaces arent removed fromthe Satellite DB after become obsolete.
E.g. in case of case 01697184, CU has host running docker connected to satellite, which is creating, using, removing virtual network interfaces which have it's entries in Satellite database. Once the virtual interface becomes obsolete, it is not removed from the DB, are still visible in Satellite UI and in case it is bigger number of them (hundreds, thousands) they are causing trouble with GUI to work quickly/properly or at least load.
Version-Release number of selected component (if applicable):
Sat 6
How reproducible:
By host running docker to Satellite server creating virtual network interfaces.
Steps to Reproduce:
1.
2.
3.
Actual results:
Obsolete network interfaces not removed from the DB.
Expected results:
Obsolete network interfaces to be removed from the DB by some automated routine
Additional info:
At this moment, the workaround is delete the entries manually from the DB but this is not what we could expect our customers would be doing on regular basis.
The patch that is associated with this BZ does not solve this BZ, it's a different kind of a workaround that "adds docker into ignore filter". New BZ should be created for this and we should take a look on proper solution to this problem - old NICs are not getting removed from DB making the import slower and slower killing Satellite 6.2 instance up to swapping and OOM.
This is very annoing and dangerous bug, the fix attached does not fix the issue (many NICs created), it only workarounds some group of hosts which are atomic/docker. We have reproduced the same behavior in labs yesterday without docker (with libvirt hypervisor):
https://bugzilla.redhat.com/show_bug.cgi?id=1440825
Due to history of the bug and attached cases, I've updated the subject of the BZ.
Please file a new BZ with specific steps that we should do to handle this situation, probably against the Networking interface.
If I remember correctly, we discussed this with Marek some time ago and we have not found a better solution than this. Perhaps when taking more such cases into account, there might be a better solution. But I think the change being this BZ is still valid and useful for the users.
Comment 13Satellite Program
2018-02-21 16:54:17 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.
>
> For information on the advisory, and where to find the updated files, follow the link below.
>
> If the solution does not work for you, open a new bug report.
>
> https://access.redhat.com/errata/RHSA-2018:0336