On Monday, June 23, 2014 6:49:00 PM UTC+2, pablo.f...@cscs.ch wrote: > > Hi, > > I think you (example42) hit the nail in the head in the "rethinking > modules part 1" with one tiny exception... but that error was multiplied > by x100 in the second part of your dissertation. > > The exception I am talking about is the desirability to pass a template > as a parameter: I agree you should be able to pass a different template, > but I think that should be the exception for extreme cases. The idea of > the parameters is precisely to avoid passing a file!! > > In my ideal world, where I manage several heterogeneous systems, I want > to be able to glance at one file and see how one node or cluster is > configured: that would be the hiera data. Having a complex hierarchy > with three or four files to check is already a burden... but it's quite > acceptable for the sake of avoiding duplicities. But if I have to check > every different template that is passed to the modules to understand > what is going on, this capability is completely lost. >
You might be misunderstanding the point about the possibility to pass a template as a reusability option. I'm not saying or advocating the idea of having a template for each node, I just think it's a needed reusability feature. If a class or a define exposes parameters to allow the modification of different variables in a template that's perfectly ok for me, that's the intended usage of templates. 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. So that, when I want to create a virtualhost file in the way I want, I have to study and accomodate all the parameters to obtain what I need, when I could just pass a custom template and use a few of the core parameters (Virtualhost name, document root and so on) to populate it dynamically. 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 here: https://github.com/example42/puppet-tp/blob/master/manifests/conf.pp#L19 ) here you can place any application specific setting without the need to add parameters to the define (in your template, of course, you have to use and manage this hash). The intended usage of defines like tp::conf which rely entirely on external templates or files, is inside higher abstraction modules, where you can expose the parameters you want and which provide a specific template that may use the exposed parameters, keeping static what you don't need to modify in your nodes. > > I am an advocate of the current trend: make good modules that serve > everyone (with a restricted purpose), and improve them so that it really > serves everyone and they don't to fork (contribute!!). Then higher > abstraction modules with wider purpose, configurable so that it serves > many people too, and there you go. So, exactly what you described in the > part 1... but not in the part 2, sorry. > Hope my clarification exposes better the rationale behind the second part. Thank you Al > > My two cents! > 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/ea615159-033d-4edf-aafd-47545a4b5f24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
