For some visibility I wanted to share the RFC that’s currently being worked on. The short summary is that Facter 2 is Ruby, Facter 3 is C++ but for Facter 4 Ruby is considered again. It should be a drop in replacement for Facter 3.
Holy crap. Why I am not surprised.
Discovery is still on facter2. Honestly, I am very tempted to skip upgrade to facter3 and simply design discovery-ng to be facter-tool independent. Meaning that facter or ansible would be completely optional (complementary data for rule-based provisioning). Discovery process would succeed even if none of them were available. Relying on our fact importing NIC heuristic very much limits what users can do with discovered nodes.
This is IMHO a good place to be opinionated and simply use facter. The upgrade to support Facter 3 by using CLI and parsing the output of facter --json. This interface has worked for many versions so should be safe to use.
The problem with facter is it does not provide enough information about NICs, foreman NIC parsers try to “figure out” bonds, bridges, virtual interfaces from the interface identifier which is very clunky. On top fo that, facter reports dozens of irrelevant facts (ssh keys, uptime, kernel and OS version info) which are useless in the discovery context.
However upgrading to facter3 will be the easiest thing to do, I don’t have time to do this 
Has there ever been an issue raised against facter to add that information? It’s probably not hard to add the facts and much easier than the guessing we do on our side.
Is it possible to change our installer in a way that this fact would be automatically distributed to clients? If this is possible and you can help me with this, then let’s do it. The fact only needs to find ifindex of all interfaces and then iterate over interfaces and find all master interface’s ifindices and pair them with interface names.