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.