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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.