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
> <[email protected]<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 <
>>> [email protected]> 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 [email protected].
>>>>
>>>> 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 [email protected] <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 [email protected].
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.
