I added some debug statements to investigate further. There seems to be a cascading effect when considering the full picture.
To paint the full picture, I started my scenario again with the bonding+vlan setup.
First of all the hosts is deployed with two network interfaces, say eth0 and eth1. Afterwards salt changes the configuration to a bond+vlan setup, say bond0 and bond0.128.
In that case both the bond and the vlan obtain the mac-address of one of the slave interfaces in the bond. What is important is that the vlan interface also obtains the same IP address that was previously assigned to eth0.
The new interface information for bond0 and bond0.128 will be sent to foreman. The information is handled in the foreman core set_interface method. That method replaces the interface eth0 with the information of bond0.128. Ergo, eth0 dissappears.
Debugging showed that the variables in that method hold the following,
iface.identifier = bond0.128
iface.identifier_was = eth0
Now that could be just fine iff the interface information of eth0 is properly updated by foreman_salt. But as we saw in the previous posts, that is not the case.
Question 1: Is it correct behavior that in foreman core the physical interface is removed in favor of a virtual interface?
If problem 1 is correct behavior, fixing the missing interface definitions in the facts in foreman_salt for eth0 and eth1 (as described in the preceding posts, could actually fix (or work around) the issue. However when the information of eth0 and eth1 is properly sent to foreman, they are added as new interfaces, resulting in duplicate entries.
Question 2: Is it correct behavior that if an interface is updated in foreman, while the identifier remains the same, but the mac-address and the IP address has changed, that it is added as a new interface instead of merged with the existing one with the same identifier?
I’d love to hear your thoughts on this.
I’m also interested to known how this process works with puppet, is it really working without issues? Or could it be that bond+vlan issue is never discovered because it seems to require a very specific scenario (matching IP address and mac-address of vlan with an interface). Furthermore it is difficult to notice, unless subsequent salt/puppet runs are depending on the that specific information from foreman.