On Nov 16, 2006, at 4:38 PM, [email protected] wrote:
On Fri, 17 Nov 2006, Luke K. wrote:
I’m skipping any fact that matches /key/ here because Facter knows
how to retrieve SSH keys, which are huge and would have polluted
the output. I had to pick between confusing people by skipping
those values, or confusing people by including them. 
okay - it makes perfect sense then
Okay. whew
well, i happen to be working on resource requests for ruby queue, eg
rq queue submit --requirements=“cpu > 3.0mhz and mem > 64gb” –
job.rb
Yeah. There are currently very limited facts for cpu and memory
information, but they could be expanded pretty easily.
By the way, I’ve been using the term ‘confine’ to describe matching
these requirements; as in, ‘confine this code to hosts that match
these requirements’. Facter uses this internally to confine a
resolution mechanism to specific platforms or organizations. E.g.,
here’s how you set up one of the ways to retrieve the hostname on OS
X (darwin):
Facter.add("Hostname") do
confine :kernel => :darwin, :kernelrelease => "R7"
setcode do
%x{/usr/sbin/scutil --get LocalHostName}
end
end
You can confine resolutions based on any other fact values.
Puppet providers (the low-level code that handles things like
different package types or different user management tools) use a
similar mechanism. Mostly I confine providers based on available
binaries:
Puppet::Type.type(:package).provide(:dpkg) do
confine :exists => “/usr/bin/dpkg”
…
end
But you can also confine just like in Facter:
Puppet::Type.type(:package).provide(:darwinports) do
confine :operatingsystem => :darwin
…
end
So, not saying you have to adopt my terminology or something, but
I’ve been pretty happy with it.