Craig, Not sure to have understood the difference between a defaults.pp pattern and a params.pp pattern, given that I suppose that if there were parameters in the main module class of Gareth's example they would inherit values in params.pp exactly as the defaults example you've written. Can be elaborate or link examples of this defaults.pp pattern?
To the list of public modules skeletons let me add this one, that follows stdmod naming conventions: https://github.com/stdmod/puppet-skeleton-standard and this alternative with Rip's data in module approach: https://github.com/stdmod/puppet-skeleton-standard/tree/hiera Al On Wednesday, February 26, 2014 10:37:59 AM UTC+1, Craig Dunn wrote: > > > This is cool, though I realise that it's a (self confessed) opinionated > module design, the only thing that really stands out for me is that it > follows a rather old, and limited, 'params.pp' pattern. There is no place > for Hiera in this model without hard coding hiera lookup functions in the > classes. Personally I think a 'defaults.pp' pattern is more sensible in > todays Puppet. > > Eg: > > class base ( > $parameter = $base::defaults::$parameter > ) inherits base::defaults { > ... > } > > class base::defaults { > $parameter = $logic ? { > 'foo' => 'bar' > } > } > > > Your classes can then look up values as $base::parameter. This allows the > module to default (rather than dictate) attributes based on whatever logic > you want to implement but allows the implementer to override the values > either at the resource declaration or using Hiera data mapping for > base::parameter. > > Regards > Craig > > > > On Wed, Feb 5, 2014 at 5:38 PM, Gareth Rushgrove > <gar...@morethanseven.net<javascript:> > > wrote: > >> This came up in discussion a couple of times at the Puppet contributor >> summit at Config Management Camp in Gent over the last couple of days >> so I thought I'd write up. >> >> A while ago I put together a pretty complete/opinionated skeleton for >> puppet modules. Especially if you're not too familiar with ruby or the >> ruby ecosystem, or just getting started with testing it should be a >> useful starting point. >> >> https://github.com/garethr/puppet-module-skeleton >> >> I've added a bunch more features (including a Guardfile, resource >> coverage and support for Beaker integration tests) and got round to >> writing up a blog post about what and why: >> >> http://www.morethanseven.net/2014/02/05/a-template-for-puppet-modules/ >> >> Hopefully it's useful to a few people. Any features or issues let me know. >> >> Gareth >> >> -- >> Gareth Rushgrove >> @garethr >> >> devopsweekly.com >> morethanseven.net >> garethrushgrove.com >> >> -- >> 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...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/CAFi_6y%2BiRQPPKk8yTLBMiHCNOsLdNFYeaPO8oTCCcuaASj6SaQ%40mail.gmail.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > *Enviatics *| Automation and configuration management > http://www.enviatics.com | @Enviatics > Puppet Training http://www.enviatics.com/training/ > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/feaadcb3-cc99-45c3-825d-57ba26dc4dc0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
