Puppet Labs released Facter 1.7 this week, introducing a number of under-the-hood enhancements and a new feature called "external facts" that's been waiting in the wings for about a year now. Facter is a cross-platform library for gathering information about nodes managed by Puppet, including domain names, IP addresses, operating systems, Linux distributions, and more. External facts provide a simple way for a puppet agent to provide custom facts without having to write Ruby. Eric Sorenson, Puppet's open source product owner, told me, "they're probably the easiest way for people to get an entry into Puppet for extending Puppet or customizing Puppet for their own site." Until this release, external facts were provided as part of stdlib, a Puppet module that provides a collection of resources and functions to assist with Puppet module development. Though stdlib's external fact support was useful, "the out-of-the-box experience wasn't as good as it could be," said Eric. Hailey Kenney, who interned at Puppet Labs last summer, wrote what Eric calls "a great implementation" of external facts for Facter, "but we didn't have a release vehicle until now." The simplest external facts are nothing more than simple text files containing key/value pairs. As Eric notes, "You can literally just drop files with 'some name equals some value' in a directory and they'll automatically get turned into facter facts." Like this:
Place the file into the proper directory (on a Unix or Linux system it will be
key1=value1 key2=value2 key3=value3
/etc/facter/facts.d; on Windows there are different locations depending on the version) and Facter will start reporting the new facts. According to Eric, "a real common use for this is, there's a lot of data AMIs on Amazon leave on-system. You generally want to import some of the info that's contained in them into Facter, but it's hard to do without external facts support." External facts make the process of gathering this information and providing it through Facter much more direct than it might have been with a Ruby custom fact. "The data's already there in this format. It makes a lot more sense to read it in in the native way, rather than do a complicated round-trip thing, then make Ruby [that] parses it then puts it back out as the same thing it started out as." If you prefer JSON or YAML, you can also write your custom facts in either of those formats. Whichever format you choose, external facts are a great way to capture node information that might be computationally expensive to retrieve, and handle retrieval only once in a while, maybe by writing a script that runs via cron. You can also use the same script to return facts straight from Facter, provided it outputs the same
key=valueformat Facter expects for a plain text file. Make sure the script is executable and drop it into the same
facts.ddirectory you'd place a plain text file, and Facter will start using its output to provide facts. If you're interested in reading more about external facts, make sure to visit the docs on custom and external facts on the Puppet Labs docs site.
Facter Has More Facts, TooAs with most Facter iterations, the new release includes a collection of new core facts:
- ZFS version and zpool membership
- Mounted Linux filesystem types
- Facts related to Solaris zones (a node's zone name and zones available on a system)
And Something for Fact DevelopersFinally, Facter 1.7 introduces a new DSL method,
on_flush. From the release notes, the new method "allows the fact author to register a callback Facter will invoke whenever a cached fact value is flushed. This is useful to keep a set of dynamically generated facts in sync without making lots of expensive system calls to resolve each fact value." If you're interested in using this new DSL method, writing new external facts, or taking advantage of the improved support for OpenWRT, you can download Facter 1.7 as a tarball, RPM, or .deb file from the Puppet Labs download site.