b011f42591
This commit moves conditionals based on values obtained from Facter inside code blocks that are only executed on agents and replaces the use of Facter['osfamily'].value with Facter.value:(:osfamily). Without this change we are returning values based off the master's facts, so if a Debian agent checks into a RedHat master then the type is currently making a decision based off of RedHat and not the actual OS of the agent running the catalog. Code ran outside blocks is evaluated on masters and inside a block is evaluated by the agent when the catalog is executed. We do not notice this because all our testing uses "puppet apply" and autorequire only matters when they find a matching resource name in the catalog. The latter results in no error because the relationship is simply ignored on the Debian agent if a package resource with the RedHat name is not found. This issue was found by running facter 3, the C++11 re-implementation under the jruby and clojure implemented puppetserver. The clojure jni shim written so that facter can be ran inside of puppetserver does not implement the [] method for the Facter module but the ruby shim does. So I noticed that the code had an issue when Facter['osfamily'].value was executed on the master, which returned a not method error. Once again, something we didn't notice becuase we do not test against a master. I decided to migrate to Facter.value(:osfamily) to simply keep to an API that is consistent across both puppet and puppetserver but fixing where the code runs does actually solve the not method found error. Change-Id: I773f20e0bc1e917f6ec5fa8830f5bbfa60b6cd8a |
||
|---|---|---|
| .. | ||
| provider | ||
| type | ||