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. 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. 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/53A85A6F.6020305%40cscs.ch. For more options, visit https://groups.google.com/d/optout.
