Puppet users - Jun 2013 - 2.7 Dynamic scoping warnings - which way should I jump?

We just bumped up our master from 2.6 to 2.7 to get yesterdays
security fix, and I''m trying to clean up the Dynamic warnings ready
to push on to 3.x.

I''ve read

http://docs.puppetlabs.com/guides/scope_and_puppet.html

but can''t see a good alternative for a pattern we use to allow tuneable
settings in our modules.
Generally we provide ''sane'' default settings, but allow an
including class
to override them like this:

    class dynamic {
      $thingy_tunable = "non-default"
      include thingy
    }

where thingy looks like:

class thingy {
  # overrideable defaults
  if $thingy_tunable { $tunable = $thingy_tunable } else { $tunable
"default" }
  # .... actual resources defined here .....
}

Options I''m sort of aware of:

1. parameterized classes - heard they don''t work with include, which
would mean quite a lot of surgery.
2. Hiera ALL the things - we''ve been using hiera to configure a fair
few modules, and it''s been great.
                                     But we tend to use it for
''node-specific globals'' - I''m not sure how I could
                                     do per-module lookups using it
(without which we''d need a lot of repetition in the
                                     hierarchy.


As I said, we''re looking to get to 3.x with PuppetDB asap - wondered
which of the 2 options above are
least likely to get in the way of that?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Hey Dirk,

Yeah, we need to re-write that page, sorry. 

Class parameters are absolutely the way to go -- they''re easier to deal
with in Puppet 3, and they DO work with include, as long as you back them 
up with Hiera. The key feature to learn about is automatic class parameter 
lookup: 
http://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookup 
There''s a bit of action-at-a-distance to deal with, but it''s
super flexible
and lets you do most of what you''d want to do. 

The other thing you should learn about is the two-level "roles and 
profiles" pattern -- Craig Dunn has a post that lines up with what our 
services people have been doing, and it works really well. 
http://www.craigdunn.org/2012/05/239/ This has proven to be a nice sane way 
to do resource-like (that is, non-include) class declarations that
don''t
stomp on each other, and can involve a bit less action-at-a-distance than 
relying on Hiera''s automatic parameter lookup.

You can probably get all your things done with either all-Hiera or 
all-roles/profiles, but I think most people are using a mixture. 

Hope that helps!

N

On Thursday, June 20, 2013 6:32:14 AM UTC-7, Dick Davies
wrote:
>
> We just bumped up our master from 2.6 to 2.7 to get yesterdays 
> security fix, and I''m trying to clean up the Dynamic warnings
ready
> to push on to 3.x. 
>
> I''ve read 
>
> http://docs.puppetlabs.com/guides/scope_and_puppet.html 
>
> but can''t see a good alternative for a pattern we use to allow
tuneable
> settings in our modules. 
> Generally we provide ''sane'' default settings, but allow
an including class
> to override them like this: 
>
>     class dynamic { 
>       $thingy_tunable = "non-default" 
>       include thingy 
>     } 
>
> where thingy looks like: 
>
> class thingy { 
>   # overrideable defaults 
>   if $thingy_tunable { $tunable = $thingy_tunable } else { $tunable = 
> "default" } 
>   # .... actual resources defined here ..... 
> } 
>
> Options I''m sort of aware of: 
>
> 1. parameterized classes - heard they don''t work with include,
which
> would mean quite a lot of surgery. 
> 2. Hiera ALL the things - we''ve been using hiera to configure a
fair
> few modules, and it''s been great. 
>                                      But we tend to use it for 
> ''node-specific globals'' - I''m not sure how I
could
>                                      do per-module lookups using it 
> (without which we''d need a lot of repetition in the 
>                                      hierarchy. 
>
>
> As I said, we''re looking to get to 3.x with PuppetDB asap -
wondered
> which of the 2 options above are 
> least likely to get in the way of that? 
>
> Thanks! 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks Nick, we''re not that far from the roles/profiles approach
(always seemed like the easiest way to get nodes.pp as clean as possible).

Sounds like if we grow out at that level it''ll
cater to the special snowflake brigades demands and reduce the number
of per-node tweaks.

Is it possible to do role-profile level lookups in Hiera? If so that''s
probably
the direction we''ll take.

Looks like the class/parameter lookup is v 3.x only though ; is that
a bit of a catch-22 (can''t get to 3.x until deprecations are cleared
up;
can clean up deprecations without 3.x)?

Like most 0.24 ''veterans'', we had to do workarounds
to get the flexibility that these 3.x whippersnappers get out of the box.

"uphill, both ways ... lick the road clean with our tongues .... "
etc.

Think we''ll stick on 2.7 for a bit and get PuppetDB into the mix first,
then worry about the Brave New World thing.

On 20 June 2013 19:08, Nick Fagerlund <nick.fagerlund@puppetlabs.com>
wrote:
> Hey Dirk,
>
> Yeah, we need to re-write that page, sorry.
>
> Class parameters are absolutely the way to go -- they''re easier to
deal with
> in Puppet 3, and they DO work with include, as long as you back them up
with
> Hiera. The key feature to learn about is automatic class parameter lookup:
> http://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookup
> There''s a bit of action-at-a-distance to deal with, but
it''s super flexible
> and lets you do most of what you''d want to do.
>
> The other thing you should learn about is the two-level "roles and
profiles"
> pattern -- Craig Dunn has a post that lines up with what our services
people
> have been doing, and it works really well.
> http://www.craigdunn.org/2012/05/239/ This has proven to be a nice sane way
> to do resource-like (that is, non-include) class declarations that
don''t
> stomp on each other, and can involve a bit less action-at-a-distance than
> relying on Hiera''s automatic parameter lookup.
>
> You can probably get all your things done with either all-Hiera or
> all-roles/profiles, but I think most people are using a mixture.
>
> Hope that helps!
>
> N
>
>
> On Thursday, June 20, 2013 6:32:14 AM UTC-7, Dick Davies wrote:
>>
>> We just bumped up our master from 2.6 to 2.7 to get yesterdays
>> security fix, and I''m trying to clean up the Dynamic warnings
ready
>> to push on to 3.x.
>>
>> I''ve read
>>
>> http://docs.puppetlabs.com/guides/scope_and_puppet.html
>>
>> but can''t see a good alternative for a pattern we use to allow
tuneable
>> settings in our modules.
>> Generally we provide ''sane'' default settings, but
allow an including class
>> to override them like this:
>>
>>     class dynamic {
>>       $thingy_tunable = "non-default"
>>       include thingy
>>     }
>>
>> where thingy looks like:
>>
>> class thingy {
>>   # overrideable defaults
>>   if $thingy_tunable { $tunable = $thingy_tunable } else { $tunable
>> "default" }
>>   # .... actual resources defined here .....
>> }
>>
>> Options I''m sort of aware of:
>>
>> 1. parameterized classes - heard they don''t work with include,
which
>> would mean quite a lot of surgery.
>> 2. Hiera ALL the things - we''ve been using hiera to configure
a fair
>> few modules, and it''s been great.
>>                                      But we tend to use it for
>> ''node-specific globals'' - I''m not sure how I
could
>>                                      do per-module lookups using it
>> (without which we''d need a lot of repetition in the
>>                                      hierarchy.
>>
>>
>> As I said, we''re looking to get to 3.x with PuppetDB asap -
wondered
>> which of the 2 options above are
>> least likely to get in the way of that?
>>
>> Thanks!
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Thursday, June 20, 2013 1:08:22 PM UTC-5, Nick Fagerlund
wrote:
>
> Hey Dirk,
>
> Yeah, we need to re-write that page, sorry. 
>
> Class parameters are absolutely the way to go -- they''re easier to
deal
> with in Puppet 3, and they DO work with include, as long as you back them 
> up with Hiera.


The problem is not with class parameterization itself, but rather with 
parameterized-style class declarations.  That is, it is with specifying 
parameter values in your manifests, so that they are set during the process 
of parsing and evaluating those manifests (even if they are expressed as 
constants), and that is exactly the case that would be the most direct 
application of parameterized classes to your usage pattern.

The problem is especially with cases where declarations of a given class 
are evaluated more than once.  In fact, the approach you are using now is 
also problematic in those cases if the relevant tweak variables do not all 
have the same values in every scope where the class declaration appears for 
a given node.  That can be very difficult to evaluate, and it is a big part 
of the reason for deprecation and removal of dynamic scoping.

 
> The key feature to learn about is automatic class parameter lookup: 
>
http://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookupThere''s
a bit of action-at-a-distance to deal with, but it''s super flexible
> and lets you do most of what you''d want to do. 
>
>
Nick suggests a viable approach, but it presents a bit of a hump to 
overcome: automatic parameter lookup was not introduced until Puppet 3, so 
you cannot transition to it while you are still running Puppet 2.7.  A 
functionally comparable approach that will work in Puppet 2.7 or 3 is for 
your classes to explicitly load their configurable parameters from hiera.  
If you name your hiera keys appropriately then you can make it easy to 
transition later to automatic parameter binding, if you should choose to do 
so.

Also, about choosing hiera keys: automatic parameter binding relies on 
hiera keys corresponding to fully-qualified names of class parameters.  
This perhaps solves your issue of per-module lookups, in that different 
modules'' data use different keys.  If following such an approach leads
to
significant data duplication, then you should consider refactoring your 
manifest set.  Classes can obtain data from other classes instead of 
directly from hiera.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.