On Friday, October 11, 2013 1:09:23 PM UTC-5, Eric Sorenson wrote: > > > Thanks to everyone who kicked the tires on the experimental data in > modules feature included in Puppet 3.3.0. We got a lot of feedback, some > cool proof-of-concept modules, and a definitive conclusion to the > experiment. > > The idea of including a module-specific hiera backend is centered around > one primary use case: replacing the 'params class pattern', a common idiom > in Puppet modules that's described in the [Using Parameterized > Classes][param-classes] guide.
I guess I wasn't following this closely enough to realize that getting rid of the "params" class pattern was an objective. I thought this was a somewhat more general initiative. [...] So the proposed solution at this point is: > - enable an implicit data-binding lookup against the hiera-puppet backend > for a value of 'classname::variable' in the file > 'modules/classname/manifests/params.pp', which simplifies class definition > and provides consistency with other hiera backends. As a module author, > you'd still leave your logic for variables in params.pp, but they'd be > implicitly looked up via data bindings as the class is declared, after > consulting site-wide hiera. > Do I understand correctly that you set out to get rid of the ::params class pattern, but now you favor an approach that depends on that pattern? Why is that better than being more general: enable an implicit lowest-priority hierarchy level for values of form 'modulename::variable', drawing on data from per-module data files such as modules/modulename/data.yaml? John -- 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. For more options, visit https://groups.google.com/groups/opt_out.
