cdoughty
2012-Jun-21 22:34 UTC
[Puppet Users] Question about best practices for custom facts in puppet
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. 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? Thanks! -- 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/-/zX9gkG2KDYsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
2012-Jun-22 13:02 UTC
[Puppet Users] Re: Question about best practices for custom facts in puppet
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/-/ll-Pvu8kBeMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
cdoughty
2012-Jun-22 16:07 UTC
[Puppet Users] Re: Question about best practices for custom facts in puppet
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
cdoughty
2012-Jun-22 18:09 UTC
[Puppet Users] Re: Question about best practices for custom facts in puppet
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. On Friday, June 22, 2012 11:07:42 AM UTC-5, cdoughty wrote:> > 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/-/bx3-RlTjaEEJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.