erroneous collection of interface information in YAML output
in the presence multiple bridges AND vlans on a node foreman reports erroneous interface information in ENC output.
additional non-existent vlan sub-interfaces and duplicate entries are reported and additionally YAML generation takes a LONG time compared to nodes without vlans and bridges. facts are correct however!
an example erroneous YAML ENC output is attached as well as an "ip link show" and "brctl show" from the same node
#4 Updated by Johannes Spanier over 6 years ago
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.
#5 Updated by Marek Hulán over 6 years ago
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
To reproduce it, an exact version of your Foreman might help.
#10 Updated by Marek Hulán over 6 years ago
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.
#12 Updated by Johannes Spanier over 6 years ago
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
#13 Updated by Johannes Spanier over 6 years ago
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
#14 Updated by Marek Hulán over 6 years ago
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).
#16 Updated by Marek Hulán almost 6 years ago
- Status changed from New to Feedback
There's no way we could identify bridge interface type based only on facter output. In your case I would suggest naming bridges like br1 br2 which should help. If this is not possible you can set rule to ignore these interfaces completely so they wouldn't be created in Foreman. In order to do this, customize Provisioning Setting with name "Ignore interfaces with matching identifier" that was added in Foreman 1.10. In your case, the value would be "[ lo, usb*, vnet*, macvtap*, internal00, public ]" or if internal suffix differs per host, you could specify it as internal*.
If none of suggested solution works for you, please let us know, I'd reopen the issue.