I've made some homework. https://github.com/stdmod/puppet-wget
A wget module cloned from the existing openssh one. The git history can show how easy and quick can be to make new modules (well this one is of course a very easy one) with the same parameters patterns. I've also gathered some sample modules which explore different usage cases here: https://github.com/stdmod/puppet-modules/tree/master/modules Feel free, anybody, to add new links to modules done with these (or proposed) patterns... (bin/clone.sh is your friend). (*) We are still talking about a draft... the current ones still need a few basic definitions ... ( package or package_name? file or file_path? or config? or config_path?... still here the current list https://github.com/stdmod/puppet-modules/blob/master/Parameters_List.md ) On Friday, August 9, 2013 11:12:36 PM UTC+2, David Schmitt wrote: > > On 2013-08-09 22:56, Alessandro Franceschi wrote: > > > > > > On Friday, August 9, 2013 9:22:54 PM UTC+2, Jakov Sosic wrote: > > > > On 08/08/2013 09:10 PM, Alessandro Franceschi wrote: > > > natural to use two different parameters, like service_ensure and > > > service_enable rather than one like service_status. > > > > Oh, I see. Simpler from the user perspective but more costly from > > performance perspective... > > > > > > > there has been some concern about the amount of parameters or the > > need > > > of some of them, but I think it makes sense to give standard > > names for > > > different possible cases, even if you don't necessarily need to > > use them. > > > > Yeah, that interested me too... Imagine having like 20 modules like > > this > > one included in a node manifest... Wouldn't the compile time explode > > because of all the extra hiera lookups?! :-/ > > > > > > For sure the number of parameters has some impact , as the number of > > resources managed by the module. > > Some Puppet performance experts ( Brice, are you reading :-? ) can > > surely give better ideas of the impact of them when used on scale. > > > > I think it makes sense to make modules that provide some minimal, most > > common, reusability parameters and have the occasion to add features and > > parameters with predictable names and functions. > > This would ease the progressive refinement of a module keeping a > > standard layout. > > > > Really, we should provide and explore more examples, with different > > layouts for different modules structures, and see how this kind of > > parameters fit. > > Actually, I'm not much concerned about the compile-time performance, > given that the alternative are modules that cannot be re-used because > they encode narrow assumptions and do not provide all necessary > extension points. > > > Regards, David > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
