On Friday, January 11, 2013 2:14:46 PM UTC-6, Eric Sakowski wrote: > > Hi all, > > We've recently started exploring the role / profile / component module > described by Craig Dunn in his blog here: > http://www.craigdunn.org/2012/05/239/ and discussed on the list the other > day. As I was implementing this for > a profile using the apache module, I realized that I could make another > refinement to our approach by using > create_resources('class','<module name>') to pull our hiera data into the > apache class and override any defaults needed. > It looks good to me but there are some concerns that it will come back and > bite us in ways we don't expect > later on, when updating to Puppet 3.0. The benefit right away is that it > saves us from having to even touch > puppet forge modules to 'hierafy' them, and it is much less code to write > and maintain, simply by structuring > class param hiera data as a hash of key-value pairs instead of flat > key-value pairs in the yaml. Any guidance > or warnings or comments in general would be most helpful to us in deciding > how to go forward. >
Accepting R.I. that the approach won't break outright, I'll take up the question of subtle bite-us-later issues, plus some other issues. First, do note that the second argument to create_resources() is not expected to be a plain resource name: it is expected to be a hash, whose keys are names of resources to create and whose values are hashes of resource parameter mappings. (Perhaps you already understand that and were merely shortcutting.) Perhaps it would work with scalars as shown, but it is better to use the 'include' function if you do not intend to declare class parameters. Second, be aware that in Puppet 3, you already don't need to do anything special in your manifests to hierify the parameters of parametrized classes. Puppet 3 will automatically consult hiera for class parameter values, using keys based on the class and parameter names. This is one of Puppet 3's best advances. Although parametrized classes work fine in Puppet 3 with hiera-based parameter lookup, the same is not true of classes declared with local parameter customizations via parametrized-class syntax (in any Puppet version since parametrized classes were introduced). The problems with such declarations must also apply if you use the create_resources() function to set class parameters. The most important problem there that classes may be declared any number of times -- and there are good reasons for multiple declarations of the same class -- but only the first declaration parsed may declare explicit parameters. Furthermore, Puppet's parse order can be difficult to predict (indeed, controlling parse order is one of the most important reasons for multiple class declarations) so it may be tricky to be confident that any particular declaration will be parsed first. Even if your create_resources() appears at top scope or in a node block, you could still be bitten by the multiple-declaration issue if one of the modules you declare that way itself declares one of the others that you declare later. Worse (in this regard), if you declare multiple classes in the same declare_resources() call, then you absolutely cannot predict the order in which those classes will be declared. If, on the other hand, you use create_resources() to declare one class at a time, then you gain little. Plain 'include' combined with Puppet 3's parameter autolookup would serve you better for that purpose. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4v38QVt8GagJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
