Hi Ken, I'm happy to give my $.02, FWIW.
I've found immense benefit from the overall paradigm described in Craig Dunn's blog post here: http://www.craigdunn.org/2012/05/239/ That paradigm, combined with modules which have all of their variables placed as module::variable_name parameters which default to module::params::variable_name allows for much flexibility: - easy unit test creation. (avoiding trying to get hiera to work with unit tests made this incredibly attractive to us) - clear delineation between 'do-stuff' modules and 'implementation of the do-stuff module in my environment' profiles. This makes the 'do-stuff' modules more re-usable and generally communally consumable, as there are as few as possible environment-specific bits in the 'do-stuff' modules. Depending on the environment, this can also serve as a line in the sand as to which modules can be shared with the world and which contain secret sauce. This also has the added benefit of creating tiers of complication. You can allow your more junior people to orchestrate role modules onto servers, and provision servers. You can have your intermediate admins write, or improve profile modules. A select few can work on your do-stuff modules and help fill out other needs as they arise. This, again, is just my $.02. I'm sure there are many others whose opinions are equally as interesting and may contain more relevant suggestions for your specific implementation. On Mon, May 6, 2013 at 8:22 PM, Dan White <y...@comcast.net> wrote: > This looks great. > Some constructive criticism: > > I think “defaults" and “settings” are redundant. > Use one. > I kind of like the term “params”, but they all do the same thing. > > On May 6, 2013, at 1:25 PM, Ken Coar wrote: > > 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. > > > > > -- > 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. > > > -- 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.
