Hi, On 23/06/14 19:15, Alessandro Franceschi wrote: > As a side note I'm a bit perplex about the proliferation of parameters > in classes or defines in order to match single application specific > configuration entries. > When I look at this, for example: > https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/vhost.pp > my backbone freezes. > A huge amount of define parameters, that map Apache directives, and > not even a parameter that allows me to provide a custom template.
I agree... it sucks! But I think it sucks more to the person that wrote the module than to those using it. When you see a declaration of a vhost, written in puppet language, it's clear and self-explanatory. But if you pass a template instead, the clarity is lost: you need to look for it elsewhere, it's much more complicated to understand a template than a puppet hash, and you need to seek each variable to see where its value is coming from. The specific problem with vhosts (and other of the kind) is a problem with the language itself: Hiera does not search parameters of defined types, and you need to find your way around with a class that does a simple create_resources to create those resources of that defined type (and probably set defaults with parameters). It could be worse, though :) > Also, if you want a pure data driven setup, where you place on hiera > hashes of data with all the stuff you need, you can still have this > using a template and a single parameters ( such as the options_hash ) I have mixed feelings about this: if it's not a parameter, you don't have automatic hiera lookups, and additionally you have to properly document the structure of the hash. Parameters are almost self-explanatory... but I agree that there are some modules where everything is a parameter, and it's difficult to handle. But I think I would rather have that than doing a template do all the work and have to parameters (template and options_hash) > Hope my clarification exposes better the rationale behind the second part. Yes, I understand your approach... but I don't think it's going very far (given the current trend): Puppet has chosen the "multi-parameter" route because they want to be able to plug in different data feeds. Neither a config_hash nor a template are really feed-able. As a side note, a problem with "forking" the model: when people do fancy stuff (like the truth_enforcer - I loved the idea BTW - or using special libraries as requirements) regular users often can't profit from their modules. Too much effort lost from both sides!! I think PuppetLabs (they have the steering wheel) is more-or-less clear with how they envision the "ideal" module. As long as we stick to that, our modules will live longer and be used more often. This should not prevent us from thinking of alternatives, obviously. BR/Pablo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53A98ACA.8090800%40cscs.ch. For more options, visit https://groups.google.com/d/optout.
