For some reason the interfaces are created repeatedly, probably with every fact upload. As a temporary workaround you can disable interfaces creation by setting ignore_puppet_facts_for_provisioning to false and remove all duplicated interfaces.

Thanks Marek for the proposed workaround, I will do that until the bug is fixed. Although I think you meant set "ignore_puppet_facts_for_provisioning = TRUE". How to I go about removing the duplicated interfaces? There are a LOT of them and I do not want to do this in the WebUI for about 10 machines where this happened. Too much clicking ;-).

There remains the issue with the non-existent interfaces. In the provided example YAML output there are interfaces named internal00.100, internal00.300 and internal.700 that simply do not exist on the node at all, also the interface that is duplicated many times (ovirtmgmt.300) does not even exist on the node.
I looks like additional interfaces are erroneously reported for every possible mathematical combination of bridge names and vlan numbers on the node.

Right, it should be TRUE, I'm glad you read my instructions but carefully :-) If you know ruby you can use rails console to delete interfaces from all hosts or you can script something using hammer or foreman API. In rails console a command might look like similar to this

Nic::Base.where(:identifier => ['internal00.100', ' internal00.300', ...]).map(&:destroy)

Make sure to backup your DB before any similar changes.

I have no idea where other interfaces come from. We use fact interfaces to find all interfaces on host, which in you case is this list

"_vdsmdummy_,bond0,eth0,eth1,eth1_100,eth1_300,eth1_700,eth2,internal00,lo,ovirtmgmt,public" 

To reproduce it, an exact version of your Foreman might help.

FOREMAN: 1.7.4
RUBY: ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
PUPPET: 3.7.5
OS: Ubuntu 14.04.02 LTS

Node:
PUPPET: 3.7.5

OK. So I set "ignore_puppet_facts_for_provisioning = TRUE" and deleted all extraneous interface information. But now, after a few days, the interfaces are back in the ENC output! Probably accumulated with every facter run.

Also could some admin kindly set the "Found in release:" field to 1.7.4.

I just tested to import your facts into my Foreman (running develop branch) and I realized what's going on. Some of you interfaces seems to have same MAC but they don't follow the naming conventions on which we rely.

internal00 and public seems to have the same MAC as eth1 but since they don't have dot in their name we don't detect them as VLANs (they are VLANs right? or Alias...). This has impact on next import because then we consider them as physical so we update their attributes (identifiers). This is present in Foreman 1.8 as well and TBH I'm not sure how to properly solve this since we don't have enough information in facter output to detect proper type of interfaces with custom identifier.

One thing that might help is precreating interfaces manually with correct types (making public and internal00 VLANs before first puppet facts upload). Second solution is to upgrade to 1.8 and disable interface auto-updating.

Some of your interfaces seems to have same MAC but they don't follow the naming conventions on which we rely.

What happens is that I have ONE real interface. I create TWO VLAN interfaces from these. Namely eth1.100 and eth1.700. These have the SAME MAC address. This is the normal situation and the way it is with vlan interfaces... Can't just make up more MACs. eth1.100 and eth1.700 DO follow the usual naming convention for VLAN (sub-)interfaces.

internal00 and public seems to have the same MAC as eth1 but since they don't have dot in their name we don't detect them as VLANs (they are VLANs right?

NO. They are bridge interfaces. They use eth1.100 and eth1.700 respectively as one of their bridge ports (which both have the same MAC, inhereited from eth1). The other bridge Ports are tun/tap Interfaces for the virtual machines. They do not show up here. Same again here regarding the MAC. The MAC of the bridge interface is inherited from the (first?) bridge member.

So in the end eth1, eth1.100, eth1.700, internal00 and public all have the same MAC, which is just the normal operating mode of linux networking.

eth1 <- host interface |
+- eth1.100 <- vlan interface | | | +- internal00 <- bridge interface |
+- eth1.700 <- vlan interface |
+- public <- bridge interface

Dang. nice ASCII art with interface associations broken. Should have known...
This time with formatting...

eth1            <- host interface
  |
  +- eth1.100         <- vlan interface
  |  |
  |  +- internal00    <- bridge interface
  |
  +- eth1.700        <- vlan interface
     | 
     +- public        <- bridge interface

Thanks, the overview helps. VLAN interfaces are OK. The issue in this case I think are bridges because we don't detected that they are bridges. We consider interface being a bridge only if it's name is br# or virbr# (https://github.com/theforeman/foreman/blob/develop/app/services/fact_parser.rb#L4). Since your bridges doesn't have underscore in name they are not even considered as virtuals (bridge would be) so they are considered physical and hence they can be renamed (same MAC as eth1).