Puppet users - Nov 2012 - Params classes and best practices

Hi all,

I''ve been wondering what is considered best practice when it comes to
$module_name::params classes? I see for instance the latest versions
of the apache and mysql modules from puppetlabs use static variables
which cannot be overridden:
https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params.pp
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/params.pp

But what if I want to install apache with ssl disabled? I see a few
options, all horribly bad:
1) change the params.pp file to set $ssl = false
2) change the module to use either hiera or class parameters which
allow setting this configuration flag.
3) In the older days, we used to use a mechanism that allowed for
top-scope variables to set a module level variable. This was also
messy, but at least it worked:
https://github.com/Tribily/puppet-mariadb/blob/master/manifests/params.pp

I''d be happy to hear what ''we'' consider industry
standard. I''m leaning
towards class parameters for configuration variables that need to be
different from deployment to deployment.

cheers,

-- 
Walter Heck
CEO and Founder @ OlinData (http://olindata.com)
Puppet training and consulting
--
Follow @olindata on Twitter and/or ''Like'' our Facebook page at
http://www.facebook.com/olindata

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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 Friday, November 16, 2012 4:12:13 AM UTC-6, Walter Heck - OlinData.com 
wrote:
>
> Hi all, 
>
> I''ve been wondering what is considered best practice when it comes
to
> $module_name::params classes? I see for instance the latest versions 
> of the apache and mysql modules from puppetlabs use static variables 
> which cannot be overridden: 
>
>
https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params.pp
>
>
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/params.pp
>
>
How odd.

 
> But what if I want to install apache with ssl disabled? I see a few 
> options, all horribly bad: 
> 1) change the params.pp file to set $ssl = false 
> 2) change the module to use either hiera or class parameters which 
> allow setting this configuration flag. 
> 3) In the older days, we used to use a mechanism that allowed for 
> top-scope variables to set a module level variable. This was also 
> messy, but at least it worked: 
> https://github.com/Tribily/puppet-mariadb/blob/master/manifests/params.pp 
>
> I''d be happy to hear what ''we'' consider industry
standard. I''m leaning
> towards class parameters for configuration variables that need to be 
> different from deployment to deployment. 
>
>
I would have to say that the standard, to the extent there is one, is to 
rely on hiera for feeding data to modules.  Classes can access 
hiera-provided data in a variety of ways, and foo::params classes can be 
fit into the picture in a variety of ways, but the key thing that the 
examples you pointed out fail to do is to decouple their main classes from 
a particular data source.  That''s what hiera brings to the table.

With respect specifically to foo::params or similar classes, I think there 
are two patterns that are widely accepted and respected:

   1. Use a ::params class to provide *default* values in the event that no 
   other value is supplied by hiera (or some other means), or
   2. Use Hiera''s puppet back end to integrate data from the class
directly
   into your data hierarchy.

There are different ways to implement those approaches, with somewhat more 
controversy attending them, but I think the basic ideas are pretty solid.

Also, do not be distressed if you were hoping for the One True Pattern for 
this sort of task.  If you look a bit deeper, you will see that those two 
patterns are really variations on the same theme.


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/-/mGSL9RqJJFcJ.
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.