In my mind the "purest" way would be to go individual modules for each package/service combination. If the only requirement is that you are handling the differences between Red Hat and Debian flavours, then a module per package/service. These modules would be wholly self contained and rely on some of the standard set of Facter facts. And then you could publish them :-) It would also avoid future duplicate resource declarations where someone's embedded "packageX" into one profile, and it clashes with "packageX" in another profile.
I can see the argument for putting package installs and service starts into a profile but only if it's global for every operating system. So if there was profile::webserver that needed Package[openssl] and that was correct for all operating systems, then fine. However if you have to start doing conditional logic to find the right name of Package[openssl] for Red Hat and Debian, then profile::webserver is not the place. profile::webserver is a container of business logic that relates wholly and only to your business and your team. The exact implementation of Package[openssl] has nothing to do with profile::webserver, as long as openssl gets there somehow, that should be all you care about at the Profile level. Implementing Package[openssl] really depends on the operating system Facts alone, and this should be in it's own module... and... all of a sudden your profile::webserver is operating system agnostic, which is cool. Question - why is it taking your team getting annoyed at generating boilerplate code? Surely you have some sort of "puppet module create" wrapper script or you use https://github.com/voxpupuli/modulesync? If you've got so much overhead adding boiler plate code for your boring modules then I think you're tackling the wrong problem... If you can bring the boiler plate code problem down to 1-2 minutes, it's got to only take another 5-10 minutes tops to refactor one package{} and one service{} resource out of the profile and into it's own module, and then your team argument kind of goes away. Question - why are you writing 120 modules yourself? Are there really no other implementations of these things on the Forge or GitHub? -- Luke Bigum ----- Original Message ----- From: "J.T. Conklin" <j...@acorntoolworks.com> To: "puppet-users" <puppet-users@googlegroups.com> Sent: Tuesday, 19 April, 2016 01:47:37 Subject: [Puppet Users] Strategies for "boring" packages 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. 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? Thanks for sharing, --jtc -- 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/87shyio252.fsf%40wopr.acorntoolworks.com. For more options, visit https://groups.google.com/d/optout. --- LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN http://www.LMAX.com/ Recognised by the most prestigious business and technology awards 2016 Best Trading & Execution, HFM US Technology Awards 2016, 2015, 2014, 2013 Best FX Trading Venue - ECN/MTF, WSL Institutional Trading Awards 2015 Winner, Deloitte UK Technology Fast 50 2015, 2014, 2013, One of the UK's fastest growing technology firms, The Sunday Times Tech Track 100 2015 Winner, Deloitte EMEA Technology Fast 500 2015, 2014, 2013 Best Margin Sector Platform, Profit & Loss Readers' Choice Awards --- FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved. This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). This message is not intended for any recipient(s) who based on their nationality, place of business, domicile or for any other reason, is/are subject to local laws or regulations which prohibit the provision of such products and services. This message is subject to the following terms (http://lmax.com/pdf/general-disclaimers.pdf), if you cannot access these, please notify us by replying to this email and we will send you the terms. If you are not the intended recipient, please notify the sender immediately and delete any copies of this message. LMAX Exchange is the trading name of LMAX Limited. LMAX Limited operates a multilateral trading facility. LMAX Limited is authorised and regulated by the Financial Conduct Authority (firm registration number 509778) and is a company registered in England and Wales (number 6505809). LMAX Hong Kong Limited is a wholly-owned subsidiary of LMAX Limited. LMAX Hong Kong is licensed by the Securities and Futures Commission in Hong Kong to conduct Type 3 (leveraged foreign exchange trading) regulated activity with CE Number BDV088. -- 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/40244240.12778722.1461054269361.JavaMail.zimbra%40lmax.com. For more options, visit https://groups.google.com/d/optout.
