> > > 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.
The param node classes basically insist that class declaration happens as close to the node scope as possible. Soon puppet will start warning if you use dynamic scoping and after that dynamic scoping will stop working this means 'include' as we know it will stop working and might as well be removed from the language. This means every "node" block is now heavy with lots of parameters and because you have to declare the classes there you should also declare dependencies at that level for it to be clear. It also means each node block is full of data - the parameters - and the data is duplicated between nodes So in order to get DRY node blocks where adding a new node isnt a nightmare or where changing a property on 10s or 100s of nodes isnt a problem I see users using extlookup to lookup data that they then pass into param class declarations due to the lack of PDL. The solution being proposed is so dissfunctional that users are forced to combine the new functionality with that 'hack' you are replacing just to get work done. This discourages code separation into multiple classes - think a class for the package, service and config each. Instead promotes big classes that does lots of tings because writing multi class modules has become MUCH more complex since declaring those classes now requires node data passed between them. The answer here to prevent this duplication and complexity is use an ENC, if you use an ENC to declare your classes the duplication happens outside of Puppet in a place people dont feel the pain. This leads us down a road where an ENC is now a dependency, to use Puppet you need and ENC because Puppet Labs is making language decisions that make any other use impossible or untenable. This is a huge concern, how long till the only way to get complex modeled data support into Puppet do you have only 2 options, code in another language yourself or pay for a commercial ENC? By pushing more and more and more into ENC's aren't we admitting that we've given up the struggle with the Puppet DSL? Aren't we just saying we cant solve these problems with Puppet and its declarative language therefore we go out to a full language like Ruby where we can query databases to access paramters of nodes and other nodes because Puppet doesnt provide a DSL level search functionality? Where we can use full procedural loop constructs to declare classes, where we are creating resources based on hashes passed in from an entirely different language. You might as well just not use Puppet once you've reached this level of complexity in your ENC. -- R.I.Pienaar -- 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.
