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.
···
On Nov 16, 2006, at 4:38 PM, ara.t.howard@noaa.gov wrote:
On Fri, 17 Nov 2006, Luke Kanies wrote:
--
Luke Kanies
http://madstop.com | http://reductivelabs.com | 615-594-8199