(#12357) Make facter_dot_d look in Puppet[:confdir]/facts.d #44
Conversation
Without this patch the PE modules don't have a way to identify a filesystem path where it's OK to place variable data related to managing the target node. This is a problem when a module like pe_compliance needs to write a wrapper script to the node's filesystem. This patch addresses the problem by exposing the node's Puppet[:vardir] setting as a Facter fact. This fact value will be set to `nil` if Puppet is not loaded into memory. If Puppet is loaded, e.g. using `facter --puppet` or using `puppet agent` or `puppet apply` then the fact will automatically set the value to Puppet[:vardir] The value of this setting is subject to Puppet's run_mode. This patch implements a new utility method in the standard library module named `Facter::Util::PuppetSettings.with_puppet`. The method accepts a block and will only invoke the block if the Puppet library is loaded into the Ruby process. If Puppet is not loaded, the method always returns nil. This makes it easy to define Facter facts that only give values if Puppet is loaded in memory.
|
Previous pull request: #40 |
On Windows, we have no folders that match up to the default set of
directories the facter_dot_d fact looks in by default. This is a
problem because the Puppet Enterprise installer writes out the following
facts by default, and our modules require them to be present:
% cat /etc/puppetlabs/facter/facts.d/puppet_enterprise_installer.txt
fact_stomp_port=61613
fact_stomp_server=puppetmaster
fact_is_puppetagent=true
fact_is_puppetmaster=true
fact_is_puppetconsole=true
On windows, the Puppet confdir is quite variable. On 2003 systems we
default to the All Users application data directory. On 2008 systems we
default to the ProgramData directory. The actual configuration
directory varies depending on the Puppet or Puppet Enterprise branding.
In order to simplify all of this variable behavior, this patch fixes the
problem by automatically looking for facts in
`%COMMON_APPDATA%/PuppetLabs/facter/facts.d`
This patch paves the way for the MSI installer to use an IniFile element
to write custom facts during installation.
|
@joshcooper Could you take a look at this again? Your comment was removed from this discussion because it was on the commit itself rather than the diff tab. (I rebased that commit away). |
…settings_facts (#12357) Make facter_dot_d look in Puppet[:confdir]/facts.d
| def with_puppet | ||
| begin | ||
| Module.const_get("Puppet") | ||
| rescue NameError |
There was a problem hiding this comment.
This is a whole lot of magic, right here. It should have some comments to explain what it is all about.
There was a problem hiding this comment.
Yeah, this is a case where it didn't seem like magic at all when I wrote
this. It's the third or fourth time I've done something like this so it
feels obvious to me now. If I put myself in the shoes I was wearing the
first time I drew this pattern it'd have been obvious that I needed to
comment this more clearly.
Will keep this in mind and add comments if I'm in this code again soon.
There was a problem hiding this comment.
On Thu, Mar 8, 2012 at 10:12 AM, Daniel Pittman
[email protected]
wrote:
@@ -0,0 +1,17 @@
+module Facter
- module Util
- module PuppetSettings
- class << self
- def with_puppet
- begin
- Module.const_get("Puppet")
- rescue NameError
This is a whole lot of magic, right here. It should have some comments to explain what it is all about.
I found myself back in the code today and this comment should be
addressed in #50
-Jeff
On Windows, we have no folders that match up to the default set of
directories the facter_dot_d fact looks in by default. This is a
problem because the Puppet Enterprise installer writes out the following
facts by default, and our modules require them to be present:
On windows, the Puppet confdir is quite variable. On 2003 systems we
default to the All Users application data directory. On 2008 systems we
default to the ProgramData directory. The actual configuration
directory varies depending on the Puppet or Puppet Enterprise branding.
In order to simplify all of this variable behavior, this patch fixes the
problem by automatically looking for facts in Puppet[:confdir]/facts.d
There is no change in behavior if Puppet is not actually loaded into
memory.
This patch paves the way for the MSI installer to use an IniFile element
to write custom facts during installation. Since we're already writing
custom data into the puppet.conf file, and the 'facts.d' directory will
be a sub-folder of the folder containing puppet.conf, we'll be
reasonably guaranteed this implementation will be robust for all Windows
platforms that Puppet itself runs on.
(#12357) Add puppet_vardir custom fact
Without this patch the PE modules don't have a way to identify a
filesystem path where it's OK to place variable data related to managing
the target node. This is a problem when a module like pe_compliance
needs to write a wrapper script to the node's filesystem.
This patch addresses the problem by exposing the node's Puppet[:vardir]
setting as a Facter fact.
This fact value will be set to
nilif Puppet is not loaded intomemory. If Puppet is loaded, e.g. using
facter --puppetor usingpuppet agentorpuppet applythen the fact will automatically setthe value to Puppet[:vardir]
The value of this setting is subject to Puppet's run_mode.
This patch implements a new utility method in the standard library
module named
Facter::Util::PuppetSettings.with_puppet. The methodaccepts a block and will only invoke the block if the Puppet library is
loaded into the Ruby process. If Puppet is not loaded, the method
always returns nil. This makes it easy to define Facter facts that only
give values if Puppet is loaded in memory.