On May 14, 8:52 am, Simon J Mudd <sjm...@pobox.com> wrote: > sjm...@pobox.com (Simon J Mudd) writes: > > > john.bollin...@stjude.org (jcbollinger) writes: > > > > In fact, Puppet Labs's own recently updated style guide recommends > > > against using extlookup(), though that position is controversial. > > > I found the URL:http://docs.puppetlabs.com/guides/style_guide.html > > > "The extlookup() Function > > > Modules should avoid the use of extlookup() in favor of ENCs or other > > alternatives." > > > The statement is clear, but it would be nice to know the reasoning. > > That is if there's a problem with extlookup() then it would be good to > > know what it is. This may have been discussed elsewhere but it > > shouldn't be necessary to have to go and search for this. > > In the end I > did.http://groups.google.com/group/puppet-users/browse_thread/thread/34e4... > It is a good read.
Now you know what I meant when I called Puppet Labs's style recommendation "controversial." Personally, I remain unpersuaded that the recommended style is a good technical choice for most people, but I will not rehash the arguments that you have just read. > However, from the discussion a few things strike me: > > 1. the use of parameterised classes is recommended heavily. I've just > found out about this "new feature" inspite of using puppet for a long > time. Hence many recipes that I'm using are not paremeterised and I > have a large number of similar classes. This is certainly worth fixing > but is quite a painful transition to make given the number of systems > in use and the chance of creating heavy breakage during that change. > So if you haven't used parameterised classes much that's the first > thing that needs looking at. If you have a complex set of manifests that do not use parameterized classes, then I think it much safer to coalesce similar classes with the help of extlookup() than by attempting to switch to parameterized classes. There are a couple of important ways (other than parameterization itself) by which parameterized classes differ from non-parameterized ones, and the more complex your current manifests, the more likely these are to bite you if you parameterize existing classes. Note, however, that it is the use of extlookup() *as an alternative to class parameterization* that the style guide recommends against. Do not take it as a blanket recommendation against using the feature. Note also that another part of the Style Guide's approach is that classes should avoid including other classes. Although it may not be immediately obvious, that goes hand-in-hand with extensive use of parameterized classes. Do take that into consideration as you evaluate the Style Guide's recommendations. > [...] if you already have working recipes > perhaps and aren't using an ENC [, extlookup] gives you a way to > clearly remove the conditional logic the recipes currently have. It's > then a smaller step "up" to using an ENC if you want to go that > way. For those that don't it still becomes reasonably clear where the > configuration is parameterised and how/why that's done, so it's still > a more flexible approach. I agree. Furthermore, I maintain that if you are not using an ENC, then parameterized classes offer few advantages to offset their disadvantages. Therefore, if you are not already using an ENC and do not want to switch to one right now, then extlookup() is the best generally available way to externalize your configuration's data. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
