I've been having to write (and modify) a lot of modules lately, and I've so
far moved to the following pattern. I'd appreciate comments and feedback
about my approach, particularly in light of the changes to name scoping
(all my modules are currently deployed under 2.7).
1. mod::defaults (defaults.pp)
- does *not* inherit from anywhere
- 'include mod::settings'
- references module variables with $mod::settings::varname
2. mod::base (base.pp)
- 'inherits mod::defaults'
- 'include mod'
- 'include mod::settings'
- any other things which apply to all classes in the module
3. mod::settings (settings.pp)
- does *not* inherit from anywhere
- has responsibility for resolving and normalising any global or
mod() class variables into sane values
4. mod (init.pp)
- 'inherits mod::defaults'
- 'include mod::settings'
- imports all $mod::settings::<varname> definitions into the $mod
namespace
- if it's a multi-function module (*i.e.*, classes may be selectively
called out for use), this is all it does.
- if it's a single-purpose module, the rest of its work can go here
-- or in other classes it includes
5. all other classes
1. 'inherits mod::defaults'
2. 'include mod::base'
3. does whatever else it's suppposed to do.
The ideas I'm working from are to abstract all the parameter selectors and
such into one class, resource declaration defaults into another, and the
module top-level namespace and every-class-needs-this stuff into a third.
Does this make sense, or is it completely lame? Or are there better
patterns (that don't require hiera nor puppetdb) I should consider?
Thanks!
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
