| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
renames Facter::Util::Resolution#length to weight as a more generic
mechanism for allowing resolutions to state their importance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On an OSX host:
$ facter operatingsystem
Darwin
$ facter_operatingsystem=Not_Darwin facter operatingsystem
Not_Darwin
But on a linux/solaris host:
$ facter operatingsystem
CentOS
$ facter_operatingsystem=Not_CentOS facter operatingsystem
CentOS
As the operatingsystem fact resolution for linux-based kernels has higher
precedence than the environment variable as it has more matching confines than
the value from the environment variable.
This patch adds from_environment to the resolution mechanism, which makes the
resolution have an artificially high weight by claiming the length of its
confines array is 1 billion.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch is originally by Daniel Berger <djberg96@gmail.com>, I
changed using Facter.value instead of repeatedly testing
Config['host_os'], removed Resolution::which, and fixed the specs.
Thanks to Paul Nasrat for helping with cross-platform debugging.
Signed-off-by: David Schmitt <david@dasz.at>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 33fb7709404e706801683e6c47ab7a0a5a1884b1.
This has broken master for some facts (eg OS X facts), it also breaks facter
platform support on win32 as popen3 does not work there.
I'd like to get master working, backlog of patches applied and revisit exec.
Paul
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far messages to stderr haven't been catched by
Facter::Util::Resolution.exec and were insted printed out to
stderr. This will cause facter and even puppet to print to stderr
themself, which is not very nice when running puppetd by cron,
as you might get every run a mail if a command outputs to stderr.
We are now wrapping the command execution with Open3.popen3 to
catch stderr and passing them to the new introduced Facter.warn
method.
We are also catching multiline outputs chomping newlines and
returning an array if there have been more than one line. Otherwise
we return an array containing the different lines.
This prevents in general cases as described in #2766 and should
handle command execution in a bit saner way.
|
|
|
|
|
|
| |
Fix facts added with empty blocks by handling calls to value when setcode not called
Ensure we handle load failures more gracefully
|
| |
|
|
|
|
|
|
| |
Facts that raise exceptions just return nil now.
Signed-off-by: Luke Kanies <luke@madstop.com>
|
|
|
|
| |
Without this call, every time there's a timeout, we'll get a zombie.
|
| |
|
| |
|
|
|
|
|
|
|
| |
I don't like using Fact.add(:fact, :limit => 5), so I
added a little extra code to allow us to continue using
':timeout => 5', but use 'limit' for retrieving the value,
to avoid the conflict Steve Hajducko is seeing.
|
|
|
|
|
| |
This was done to avoid a possible variable scoping issue
that was occuring on some AIX systems.
|
| |
|
|
|
|
|
|
| |
but the default is still 0.5.
Set the timeout on the AIX kernelrelease fact to 5 seconds.
|
|
This makes it easier for our loader to distinguish between
code that Facter uses and new facts.
|