On Thursday, June 20, 2013 1:08:22 PM UTC-5, Nick Fagerlund wrote: > > Hey Dirk, > > Yeah, we need to re-write that page, sorry. > > Class parameters are absolutely the way to go -- they're easier to deal > with in Puppet 3, and they DO work with include, as long as you back them > up with Hiera.
The problem is not with class parameterization itself, but rather with parameterized-style class declarations. That is, it is with specifying parameter values in your manifests, so that they are set during the process of parsing and evaluating those manifests (even if they are expressed as constants), and that is exactly the case that would be the most direct application of parameterized classes to your usage pattern. The problem is especially with cases where declarations of a given class are evaluated more than once. In fact, the approach you are using now is also problematic in those cases if the relevant tweak variables do not all have the same values in every scope where the class declaration appears for a given node. That can be very difficult to evaluate, and it is a big part of the reason for deprecation and removal of dynamic scoping. > The key feature to learn about is automatic class parameter lookup: > http://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookupThere's > a bit of action-at-a-distance to deal with, but it's super flexible > and lets you do most of what you'd want to do. > > Nick suggests a viable approach, but it presents a bit of a hump to overcome: automatic parameter lookup was not introduced until Puppet 3, so you cannot transition to it while you are still running Puppet 2.7. A functionally comparable approach that will work in Puppet 2.7 or 3 is for your classes to explicitly load their configurable parameters from hiera. If you name your hiera keys appropriately then you can make it easy to transition later to automatic parameter binding, if you should choose to do so. Also, about choosing hiera keys: automatic parameter binding relies on hiera keys corresponding to fully-qualified names of class parameters. This perhaps solves your issue of per-module lookups, in that different modules' data use different keys. If following such an approach leads to significant data duplication, then you should consider refactoring your manifest set. Classes can obtain data from other classes instead of directly from hiera. 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.
