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

On Friday, June 22, 2012 8:02:46 AM UTC-5, jcbollinger wrote:
>
>
>
> 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
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/z1p_bQ_xCqsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to