Hi Ken,
I'm not sure I fully understood the purpose of each class, and until then
I'm not pointing out issues. But if my interpretation is correct then you
may get something useful from this other pattern:
# it's probaby your mod::defaults and mod::settings together
class mod::params {
$setting1 = 1
$setting2 = 'a'
}
# entry point
class mod(
$setting1 = $mod::params::setting1,
$setting2 = $mod::params::setting2
) {
class {'mod::install': } ->
class {'mod::config':} ~>
class {'mod::service':} ->
Class['mod']
}
# the classes below reference parameters
# as $mod::setting1
class mod::install {
}
class mod::config {
}
class mod::service {
}
this can be expanded to more than one entry point.
Hope that helps.
El lunes, 6 de mayo de 2013 12:25:30 UTC-5, Ken Coar escribió:
>
> 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.
