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):
By host running docker to Satellite server creating virtual network interfaces.
Steps to Reproduce:
Obsolete network interfaces not removed from the DB.
Obsolete network interfaces to be removed from the DB by some automated routine
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.
Created redmine issue http://projects.theforeman.org/issues/16834 from this bug
Upstream bug assigned to firstname.lastname@example.org
Upstream bug component is Provisioning
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16834 has been resolved.
*** Bug 1436918 has been marked as a duplicate of this bug. ***
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):
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.
Ok I have reported this upstream:
These are trackers to fix this in more sane way.
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.