Hi all,
We've recently started exploring the role / profile / component module
described by Craig Dunn in his blog here:
http://www.craigdunn.org/2012/05/239/ and discussed on the list the other
day. As I was implementing this for
a profile using the apache module, I realized that I could make another
refinement to our approach by using
create_resources('class','<module name>') to pull our hiera data into the
apache class and override any defaults needed.
It looks good to me but there are some concerns that it will come back and
bite us in ways we don't expect
later on, when updating to Puppet 3.0. The benefit right away is that it
saves us from having to even touch
puppet forge modules to 'hierafy' them, and it is much less code to write
and maintain, simply by structuring
class param hiera data as a hash of key-value pairs instead of flat
key-value pairs in the yaml. Any guidance
or warnings or comments in general would be most helpful to us in deciding
how to go forward.
We're using Puppet Enterprise 2.7 and plan to eventually update to 3.0
later on down the line.
Here's an example of our new idea (I'm using the refactored apache from the
github refactor branch):
apache_params:
apache:
default_mods : true
default_vhost : false
default_ssl_vhost : false
service_enable : true
serveradmin : 'root@localhost'
sendfile : false
error_pages : false
apache_vhosts :
testvhost1.com : {
ip : '10.0.0.9',
port : '81',
docroot : '/tmp/testvhost1.com',
ssl : True
}
testvhost2.com : {
ip : '10.0.0.9',
port : 82,
docroot : '/tmp/testvhost2.com'
}
The code to pull from hiera (for Puppet 2.7) can then be very simple and
decoupled from the module code:
class profile::apache_stack {
$apache_params = hiera('apache_params', false)
if $apache_params {
create_resources('class', $apache_params)
}
$vhosts = hiera('apache_vhosts', false)
if $vhosts {
create_resources( 'apache::vhost', $vhosts )
}
}
That is all of the hiera data and all of the program code, aside from the
unmodified apache module.
The apache module code is completely untouched by any of this. Default
values are set in the params.pp
by the package maintainers and if hiera does not have an override in
$apache_params{'apache'} the default
comes from the module.
Here is the other way that we have been doing things, where hiera has all
defaults in yaml explicitly
sets each variable:
apache_ssl_enabled: True
apache_vhost_default_conf: 'apache/vhost-default.conf.erb'
apache_priority: '25'
apache_servername: ''
apache_serveraliasess: ''
apache_auth: false
apache_redirect_ssl: false
.
.
.
and about 35 more lines like this.
class apache::params {
if $hiera_enabled {
$ssl = hiera(apache_ssl_enabled, True)
$template = hiera(apache_vhost_default_conf,
'apache/vhost-default.conf.erb')
$priority = hiera(apache_priority, '25')
$servername = hiera(apache_servername, '')
$serveraliases = hiera(apache_serveraliasess, '')
$auth = hiera(apache_auth, false)
$redirect_ssl = hiera(apache_redirect_ssl, false)
.
.
.
and about 35 more lines like this, followed by more code to set defaults if
hiera is not enabled.
Thoughts?
Thanks very much for reading!
- Eric
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/UHAN4L56QQ8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
