On Monday, January 14, 2013 11:17:47 AM UTC-5, jcbollinger wrote: > > > > 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. > > Thanks John for the reply. It definitely works. The code I posted was copied from a working setup, not pseudo-code.
> 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. > > Understood. apache_params is a hash containing key apache w/ value <hash of apache values from hiera> > 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. > > OK, so given that I am a user of the apache module, and it is parameterized already when I install it, for Puppet 3.0 then I could simply drop create_resources call and Puppet 3 will automatically look it up in hiera? > 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. > > OK. Sounds like having my defaults come from the apache modules parameter declarations may be a problem in Puppet 3.0. I am installing a Puppet 3 master to try and test this. Any suggestions on how best to set up the error condition you describe? I have run across some error messages from puppet rdoc finding multiple class declarations. I'd like to better understand what you're talking about here -- I'll go google but any links would be appreciated! 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. > > That sounds great and probably what I will do when we eventually upgrade to Puppet 3. Basically just drop the calls to create_resources and simply include. John > > Thanks again, Eric -- 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/-/6PhlxckuKhMJ. 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.
