On 28 February 2014 10:20, Craig Dunn <[email protected]> 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:
>

Actually that's weird. I don't actually do that in any of my actual
modules based on this skeleton. I probably merged a pull request
without looking properly.

I'll fix.

Anything in params should never be referenced directly outside init in my view.

Gareth

> 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]> 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%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 [email protected].
>> 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/CACxdKhF3qheX37vQCraHnzeVP9ObmkHamruBydHq%2BneUMkq%2BeQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
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%2B-w0hs5MvLcaONfo3Ln2VYa1HK4u9QYtSLMGhLQfi4Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to