Re: Question about best practices for custom facts in puppet

[jcbollinger]

On Thursday, June 21, 2012 5:34:00 PM UTC-5, cdoughty wrote:

We're running puppet 2.7.11 and facter 1.6.1.  We're at a point where we need to start having some custom facts for our environment but we're not sure the best way to go around it, so I'm looking for feedback from the community.

I've setup custom facts with facter now and have successfully polled these and also proven that the puppet clients have access but it seems like overkill for what we're trying to accomplish.

Here's our setup.  We want to have a module that installs a DHCP on a given subset of machines(but in the future we may even have more 'roles' for other services), and our first attempt was to have a variable set in this module to the effect of "dhcpd_server_role=true".

We found that the variable wasn't available as a fact like our top level variables, and I assume this is because its out of scope.

Yes, though "out of scope" is not the same thing as inaccessible.  If the class that contains the variable is "dhcp::server" then once the class has been included, the variable is available as $dhcp::server::dhcpd_server_role.  That doesn't help you, though, because if the class is not declared then the variable is undefined, and attempts to reference it are erroneous.
 

I guess my question is, is there an easier way to set a custom variable accessible only to clients that use a specific module or is the custom facts path with ruby/facter really the only(or best) way to go about creating these?

But what you're asking for is not what you actually need.  You don't want "a variable accessible only to [certain clients]," but rather a variable that has a different value for some clients than for others (even if one of the values is undef).  Although you can make custom facts serve in this role, they're not a very good fit.  Quick and fairly easy would be to use node-scoped variables, but more forward-looking and not too much harder would be to rely on external data accessed via hiera.


John

[cdoughty]

Hi John, thanks for your reply.  That was helpful in confirming our findings so far.

I also realize though that I wasn't very clear with my description in my ultimate goal.  We only want to access this hypothetical property "dhcpd_server_rule=true" through facter, specifically by using mcollective  

So the ultimate goal is to set a property (hopefully that's only set by dhcp servers) and accessible through facter/mcollective.  With this in mind, being undefined is ok since we'll only look for cases where "prop=true".

Also, I'm not sure I see how a node-scoped variable could be set to accomplish this since the variable never seems to show up in our facter list of properties(unlike our top-level properties we set).

I will look into external data though as this isn't something I'm familiar with.  Thanks again for your input!

Chris

[cdoughty]

I actually found a solution indirectly by reading this thread:
https://groups.google.com/forum/?fromgroups#!topic/puppet-users/Qoao9GMarRs

I create a custom fact ONLY on the machine with DHCP by copying the ruby script directly to: /var/lib/puppet/lib/facter/

Then all nodes have a pre-stage where I clean that folder out entirely.  The script is then copied to that folder in the main stage, hence setting our custom fact only on that machine we care about.

In addition to the goal of wanting this property to available to facter, we also wanted the fact to move cleanly with the puppet module, so if we choose a different machine to be our DHCP server at a later time, then this fact would cleanly move with the migration.