Importing Puppet facts for provisioning - flip-flopping/failing?

Support
1

So, I have the Foreman setting “Ignore Puppet facts for provisioning” set to “No” which per the description: “Stop updating IP address and MAC values from Puppet facts (affects all interfaces)” means I AM importing these values from facter values every puppet run (or at least - I want to!).

I can see from my audit logs TONS of flip flopping as a result - and I’m not sure why.

Deep diving into a single example:

Host1 Example: Windows Server 2012 R2
No Change Puppet run came in

Audit Logs from the exact same time as the puppet run:

[
{
“user_id”:2,
“user_type”:null,
“user_name”:“foreman_api_admin”,
“version”:6136,
“comment”:null,
“associated_id”:165477,
“associated_type”:“Host::Base”,
“remote_address”:“OBFUSCATED”,
“associated_name”:“Host1”,
“created_at”:“2019-03-13 19:08:37 -0400”,
“id”:80808655,
“auditable_id”:210553,
“auditable_name”:null,
“auditable_type”:“Nic::Managed”,
“action”:“update”,
“audited_changes”:{
“identifier”:[
“tan”,
“lan”
],
“attrs”:[
{
“obfuscated”:“yes”
},
{

        }
     ]
  }

},
{
“user_id”:2,
“user_type”:null,
“user_name”:“foreman_api_admin”,
“version”:6135,
“comment”:null,
“associated_id”:165477,
“associated_type”:“Host::Base”,
“remote_address”:“obfuscated”,
“associated_name”:“Host1”,
“created_at”:“2019-03-13 19:08:37 -0400”,
“id”:80808654,
“auditable_id”:210553,
“auditable_name”:null,
“auditable_type”:“Nic::Managed”,
“action”:“update”,
“audited_changes”:{
“identifier”:[
“lan”,
“tan”
],
“attrs”:[
{

        },
        {
           "obfuscated":"yes"
        }
     ]
  }

}
]

Foreman NIC outout from GUI

eth0
Type Interface
MAC Address PROPERMAC
MTU 1500
IPv4 Address PROPERIP
IPv6 Address
FQDN PROPERFQDN
Subnet [PROPERSUBNETLINK]

eth1
Type Interface
MAC Address PROPERMAC
MTU 1500
IPv4 Address PROPERIP
IPv6 Address
FQDN PROPERFQDN
Subnet [PROPERSUBNETLINK]

lan
Type Interface
MAC Address
MTU
IPv4 Address
IPv6 Address
FQDN

Now - Facter shows two interfaces - named in the OS as LAN and TAN where LAN exactly corresponds to foreman’s “eth0” and “TAN” exactly corresponds to foremans “eth1”

Facter output:
C:\Users\me >facter networking.interfaces
{
LAN => {
bindings => [
{
address => “PROPERIP”,
netmask => “PROPERMASK”,
network => “PROPERNETWORK”
}
],
ip => “PROPERIP”,
mac => “PROPERMAC”,
mtu => 1500,
netmask => “PROPERMASK”,
network => “PROPERNETWORK”
},
TAN => {
bindings => [
{
address => “PROPERIP”,
netmask => “PROPERMASK”,
network => “PROPERNETWORK”
}
],
ip => “PROPERIP”,
mac => “PROPERMASK”,
mtu => 1500,
netmask => “PROPERNETMASK”,
network => “PROPERNETWORK”
}
}

C:\Users\me >

Now we “do” have provisioning orchestration that adds all interfaces and their information via API call(s) at provisioning time, and we do “incorrectly” label the interfaces I guess (LAN -> eth0 and TAN -> eth1) to keep things simple on the automation end.But my thought would be that enabling this operation would allow it to use MAC address as the unique identifier, and update the label(s) in foreman as well as the data/information? It “seems” like this option to populate the data from facter is completely ignoring the interfaces that are already there - and incorrectly trying to add a third interface (in a flip flop fashion).

My “goal” here is to have foreman able to update its NIC info should anything change locally, but it doesn’t seem to be happening currently, and furthermore, its causing a lot of churn as we have over 7 million audit records every 60 days just devoted to these entries (we purge at 60 days to keep the DB from ballooning…)

This doesn’t seem expected to me with this option enabled - but maybe I’m doing something wrong?