On Apr 13, 3:17 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote: > On 04/12/2011 08:24 PM, R.I.Pienaar wrote: > > > This demonstrates the problem. You have had to spend time working > > with customers to explain how to build these. It's a very complex > > subject, something our target audience in many cases dont get. They > > do understand extlookup though and it does solve a high % of their > > problems *today*. So why make their life harder. > > RI, > > I strongly disagree. When I ask Puppet Labs for help on good manifest > writing practices, I would not want to be told what crude workarounds > (no offense) are usable today. I want somewhat future-proof manifests > (if at all possible).
I am not persuaded that the current style guide achieves that result, nor that extlookup() constitutes a workaround, crude or otherwise. Indeed, I have grave concerns about the maintainability of manifests that make heavy use of parameterized classes (including otherwise ordinary classes "declared" via parameterized-class syntax). With extlookup() in the core in 2.6, I see no reason to think it any less future-proof than the new, raw implementation of parameterized classes. > Background is that we are still investing a somewhat disproportionate > amount of time into puppet development (when using puppet for managing > customers' systems). Nobody's going to pay us for refactoring work. A > style guide that recommends practices that are prone to need refactoring > in a year or two would be a huge no. I would account a desire to avoiding future refactoring as an excellent reason to avoid parameterized classes, at least for now. I like many of the recommendations in the new style guide, but not so much the ones related to using parameterized classes (and effectively making all classes parameterized). Were I you, I would look hard at the idea that it is better to allow manifest compilation to fail than to explicitly include needed classes: following that advice makes manifests substantially less resilient and thus harder to maintain. I would also consider the added work that will be involved if ever a need to change a class's parameterization arises. 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.
