Ok, I think we are talking about the same thing, then:
https://github.com/stdmod/puppet-skeleton-standard/blob/develop/manifests/init.pp.erb
should follow what you described as defaults.pp patterns , just it uses a
class named params and not default.
On Friday, February 28, 2014 11:20:57 AM UTC+1, Craig Dunn wrote:
>
>
> The main difference between Gareth's current params.pp and the
> 'defaults.pp' model I was suggesting is that in the Gareth's pattern the
> params class is inherited by the base class, and all the component
> subclasses reference the variables explicitly in the scope of
> base::params.... eg:
>
> service { $<%= metadata.name %>::params::service_name:
>
> Since the params class is not parameterized there is no way to easily
> override this data using hiera/data mapping.
>
> By making the base class parameterized, with it's defaults being set in
> 'defaults.pp' (defaults is a more sensible name than params for this
> example) and having your component subclass reference $::baseclass::var you
> can override data on class declaration or in hiera using data mapping.
>
> It's not that different, but allows for more flexibility and tighter hiera
> integration
>
> Craig
>
>
>
> On Wed, Feb 26, 2014 at 2:43 PM, Alessandro Franceschi
> <a...@lab42.it<javascript:>
> > wrote:
>
>> 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> 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.
>>>>
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/puppet-users/CAFi_6y%2BiRQPPKk8yTLBMiHCNOsLdNFYeaPO
>>>> 8oTCCcuaASj6SaQ%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...@googlegroups.com <javascript:>.
>> 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.
>>
>
>
>
> --
> *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/59c24cf9-245d-4cae-91ca-8124d68e0326%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
