On 1 March 2014 09:38, Gareth Rushgrove <[email protected]> wrote:
> 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.
>
Changed to:
service { $<%= metadata.name %>::service_name:
With the params on init making overriding in hiera easy. Cheers for
the heads up.
Gareth
> 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
--
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%2Bo1nLuvgFCj%2Bf8LV2OXbnHFqs%2BeV1QK%3D%3DFnwM%2ByxTCsw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
