We're currently arguing^w discussing the use of the params class in
conjunction with hiera lookups and we've arrived at what I think is a
pretty good pattern. Let me explain by way of example, using the venerable
ntp application
class ntp{
include ::ntp::params
Class['::ntp::params']-
We could have been talking in my cube. My points when I'm discussing this with
coworkers generally go like so...
If you use this:
class { name: }
You will only be able to declare that name once. If you declare classes like
this:
include ::name
include ::name::otherclass
Then you will be
Hi Christopher,
On 3 Mar 2014, at 17:55, Christopher Wood christopher_w...@pobox.com wrote:
We could have been talking in my cube. My points when I'm discussing this
with coworkers generally go like so...
If you use this:
class { name: }
You will only be able to declare that name
(inline)
On Mon, Mar 03, 2014 at 06:24:47PM +, Robin Bowes wrote:
Hi Christopher,
On 3 Mar 2014, at 17:55, Christopher Wood [1]christopher_w...@pobox.com
wrote:
We could have been talking in my cube. My points when I'm discussing
this with coworkers generally go like
(also inline)
On 3 Mar 2014, at 19:25, Christopher Wood christopher_w...@pobox.com wrote:
(inline)
On Mon, Mar 03, 2014 at 06:24:47PM +, Robin Bowes wrote:
Additionally, it creates two places in which the parameters can be
automatically set. eg. ntp::install::package_name and
On 28 February 2014 10:20, Craig Dunn cr...@craigdunn.org 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
On 1 March 2014 09:38, Gareth Rushgrove gar...@morethanseven.net wrote:
On 28 February 2014 10:20, Craig Dunn cr...@craigdunn.org 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
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 {
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
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
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
On Wed, Feb 05, 2014 at 06:38:24PM +0100, Gareth Rushgrove 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
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
Thank you Gareth.
Your module skeleton has helped my module development tremendously.
Even though I created my own, differently opinionated, fork most of
the skeleton is the same and your effort is greatly appreciated.
On Wed, Feb 5, 2014 at 9:38 AM, Gareth Rushgrove
gar...@morethanseven.net
14 matches
Mail list logo
