|
I think the general behavior of how custom implementation can override core facts is expected in facter 3, and is a result of the way Facter now works under the hood.
Facter 3 resolvers are not tied to a given fact, like they are in Ruby facter - they collect many related facts, and populate them all at once. This is part of how we get such a huge performance improvement - we're not calling the same commands over and over for similar facts.
Facter 2 and Ruby fact compatibility is implemented in this same way - all Ruby facts are essentially one Facter 3 "resolver". This means that they have no knowledge of core fact implementations, and, since they are run last, will happily overwrite them.
An abridged pseudocode view of what Facter 3 is doing here:
-
gather_all_filesystem_facts # Collect and set all the filesystem/disk facts with as few commands as possible
-
gather_all_network_facts # Ditto for all the networking-related things
-
gather_all_os_version_facts # Once more for all the OS-related things
-
gather_all_ruby_custom_facts # your ruby OS fact overwrites a core fact value here!
One of the things we've considered is trying to better expose this model in Facter's APIs, and make it clearer that custom facts are really running in a "virtual facter 2" within Facter 3's new model.
All of that being said: It does appear that your confine isn't being respected, which I think is a bug
|
