On 4/18/16 5:47 PM, J.T. Conklin wrote:
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
At the previous job I preferred to promote packages to full modules
from a holding module.
class vpackages {
include vpackages::params
@package { 'curl': tag => 'utils',}
@package { 'htop': tag => 'utils',}
@package { 'iftop': tag => 'utils',}
@package { 'whois': tag => 'utils', name =>
$vpackages::params::whois, }
# Mysql packages
@package { 'percona-toolkit': tag => 'mysql', }
@package { 'mysql-client': tag => 'mysql', name =>
$vpackages::params::mysqlclient, }
}
mysql-client is good example.
class mysql::install {
package { 'mysql-server':
ensure => present,
name => $mysql::params::packagename,
}
# realize packages like the client
Package<| tag == 'mysql' |>
}
Later our Mysql installations were more complicated in several different
roles with more versions. At that point it made sense to move
mysqlclient into it's own parameterized module.
What I liked about the vpackages modules is that it's a visual
representation of the shared namespace.
Ramin
--
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/5716775B.7020007%40badapple.net.
For more options, visit https://groups.google.com/d/optout.
