Puppet » Facter

My suggestion would be to look for files which match the fact name as completely as possible. So for ipaddress_eth0_0, you would look for filenames ipaddress_eth0_0, ipaddress_eth0_, …, ipaddress,… until you find a match. Code wise, I would reverse that a bit: Check wether full name exists, if it does, use it. Otherwise read in list of files starting with the same two characters (assuming that is the shortest sensible name a fact could have) as the fact wanted, sort it by length and check it from longest to shortest until a match is found.

Obviously, if underscore is considered to be a delimiter, you would only need to check for ipaddress_eth0_0, ipaddress_eth0 and ipaddress here and the logic wouldn’t need to be reversed as described above.

I still don’t know ruby well enough to work on any published code, but I might try to have a look at the relevant code late next week. I’m sure if I provide some working code, someone else will fix it up to be publishable (or guide me in doing so).

My problem was this:

$ facter | grep operatingsystem
operatingsystem => Ubuntu
operatingsystemrelease => 8.04

$ facter operatingsystem
Debian

$ facter operatingsystemrelease
lenny/sid

This problem stems from the operatingsystem fact attempting to load the lsbdistid fact, but cannot since the lsbdistid fact is located in lsb.rb rather than lsbdistid.rb

My guess is that it worked correctly the first time, just out of chance. The lsb.rb was loaded before the operatingsystem fact.

A simple solution might be to have a single file for each fact

echo "require 'facter/lsb'" > lsbdistid.rb

Doing this fixes my issues with running ‘facter operatingsystem’, however, I see that it won’t fix the issue with ipaddress_eth0_0

ian wrote:

My problem was this:

[…] […] […]

This problem stems from the operatingsystem fact attempting to load the lsbdistid fact, but cannot since the lsbdistid fact is located in lsb.rb rather than lsbdistid.rb

My guess is that it worked correctly the first time, just out of chance. The lsb.rb was loaded before the operatingsystem fact.

A simple solution might be to have a single file for each fact […]

Doing this fixes my issues with running ‘facter operatingsystem’, however, I see that it won’t fix the issue with ipaddress_eth0_0

Seems like we should fix this basic problem, and then probably put a new facter release out. I dunno if we can fix the ipaddress issue, but at the least, operatingsystem should be consistent.

Guys, this really sucks. I know you’re working on it, but it has been keeping me from upgrading puppet for the past year. Many of my config files use ERb templates that depend on these facts that now don’t work. Facter not working on the CLI is not such a big deal, but dynamic facts not being available as variables inside of puppet is a show-stopper.

I’d really like to upgrade puppet to 0.25.0, but it depends on Facter 1.5.7.

Anyone know if it is possible to get a newer puppet to work with an older facter?

Are you sure it doesn’t work in templates – puppet explicitly uses loadfacts that should load everything? I’m pretty sure it all just works.

We haven’t put a dependency on facter 1.5.7 (the gemspec is states > 1.5.1 YMMV).

FWIW I’ve been testing Puppet 0.25.0 with Facter 1.5.4 with no problems.

Just did a quick local test with a dynamic fact in a template with standalone puppet:

$ ruby -Ilib bin/puppet --genconfig | grep templatedir\ 
    templatedir = /Users/pnasrat/.puppet/var/templates

$ cat ~/.puppet/var/templates/foo.erb 
<%= ipaddress_en1 %>

$ cat test.pp 
class test_dynamic_fact {
    file { "/tmp/test_dynamic_fact":
        content => template("foo.erb"),
    }
}

include test_dynamic_fact

$ ruby -Ilib bin/puppet test.pp ; cat /tmp/test_dynamic_fact
notice: //test_dynamic_fact/File[/tmp/test_dynamic_fact]/content: defined content as 'unknown checksum'
192.168.0.2

Just to reiterate, this should work fine in Puppet, it only has issues when calling facter on the CLI.

It’s a tad hacky, but so much better than leaving this broken for 18 months.

--- facter      2010-01-14 19:05:11.000000000 +0000
+++ facter.new  2010-01-14 19:05:38.000000000 +0000
@@ -135,11 +135,10 @@
 }
 
-if names.empty?
-    facts = Facter.to_hash
-else
-    facts = {}
+facts = Facter.to_hash
+unless names.empty?
+    selectedfacts = {}
     names.each { |name|
         begin
-            facts[name] = Facter.value(name)
+            selectedfacts[name] = Facter.value(name)
         rescue => error
             STDERR.puts "Could not retrieve %s: #{error}" % name
@@ -147,4 +146,6 @@
         end
     }
+
+    facts = selectedfacts
 end

Here’s a much simpler diff that’s not hacky at all I think,

I am just making it do a full parse of the facts once before doing the previously existig logic, that sorts it all out.

--- facter      2010-01-14 19:18:32.000000000 +0000
+++ facter.new  2010-01-14 19:18:51.000000000 +0000
@@ -135,7 +135,7 @@
 }
 
-if names.empty?
-    facts = Facter.to_hash
-else
+facts = Facter.to_hash
+
+unless names.empty?
     facts = {}
     names.each { |name|

Pushed in commit:“d109def6” in branch master.