Puppet users - Jun 2012 - 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.

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.

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.

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.