Am Dienstag, 19. April 2016 03:07:34 UTC+2 schrieb J.T. Conklin: > > At work, we've written about 120 modules in our puppet code repository. > About two dozen are "interesting", in that they have lots of parameters > and configuration that is specific to our environment. The balance are > "boring", rather they are mostly boilerplate with minimal configuration. > For example, our modules abstract the differences in package and service > names between RedHat and Debian based systems. >
I tend to prefere a module if there is any difference. So I would go with modules in your case. Just for the same reasoning as you wroter later on. I think it helps with the roles/profiles pattern too, as you can include the module wherever you want. whereas you would need to include a profile from a profile when there's no module - which is something what i'd like to avoid. - Thomas > > However, there is some disagreement amongst our puppeteers about how to > handle these "boring" modules. One side objects to the amount of boiler- > plate and duplication, and would prefer that we simply define packages > in our role/profile modules. The other side claims that abstracting > package and service names is value enough to justify the overhead, and > that "boring" packages often become "interesting" over time as new > requirements for flexibility and customization develop over time. Each > group is firmly convinced that their opinion is the right one. > > So I throw the question to the puppet community... What strategies do > you use for "boring" modules so you're not overwhelmed by hundreds of > small boilerplate modules? > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b5aea085-11cf-43ff-b38a-2d25d15cbf96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
