Puppet defined resource - selective parameterization?

Question

I'm currently banging my head trying to find the "best way" to achieve this type of granularity for puppet: I have a server running memcached in testing environment and another one running for the production environment.

These servers run with different memcached options and I'm using monit to monitor and restart them if needed, monit is managed through puppet and it monitors memcached through a memcached.monitrc, pretty straightforward until so.

My problem is: I have a defined resource named "monit::monitor" which receives a name get a template for that resource, like

monit::monitor { 'memcached': }

This is the code for monit::monitor:

define monit::monitor($template_params = {}) {
    file { "/etc/monit/monit.d/${name}.monitrc":
            ensure => present,
            content => template("monit/${name}.monitrc.erb"),
    }
}

This will look for "memached.monitrc.erb" in the modules/monit/templates dir and print it out, but in that file I need to parameterize the memory parameter for memcached, if it runs in testing env it should be 64m, if in production, 3072m.

templates/memcached.monitrc.erb looks like this

 check process memcached with pidfile /var/run/memcached0.pid
  start program = "/usr/bin/memcached -d -p 11211 -U 11211 -u memcached -m <%= template_params['memory'] %> -t 4 -c 1024 -P /var/run/memcached/memcached0.pid"
  stop program = "/bin/kill -9 `cat /var/run/memcached0.pid`; rm /var/run/memcached0.pid"
  if failed host 127.0.0.1 port 11211 then restart
  group cache

What I'm using now is that monit::monitor supports a hash for templates param, but that obfuscates the template usage so you need to look at the template to see which parameters it should receive and I think that there's a better solution for this...

Thanks for the attention and sorry if it sounded confused :P

Answer 1

My solution to this kind of problem is took keep all magic numbers out of my puppet manifests and look them up when they're needed using extlookup. I have not needed to use it in a template, but it should work.

So in your case I might have

extlookup/production.example.com.csv

memcache_memory,3072m

extlookup/testing.example.com.csv

memcache_memory,64m

Then your template line would change to become

start program = "/usr/bin/memcached -d -p 11211 -U 11211 -u memcached -m <%= extlookup('memcache_memory') %> -t 4 -c 1024 -P /var/run/memcached/memcached0.pid"

and the value would automatically be set properly for each machine.

I should note that some puppet developers think that looking up data within your manifests or templates is A Bad Thing and that you should have all of your data defined in your nodes and explicitly pass it to where it needs to go through paramaterized classes and definitions. After reading that mailing list thread I still think that extlookup is the superior solution today, but you may want to read it and decide for yourself.

Answer 2

As far as I know, it is a fundamental weakness of templates that one need to refer to them to know what parameters they require. Myself, I ensure that the module documentation makes clear what variables the template requires, and the template itself can contain a comment-section with the same information.

Answer 3

Well, I wouldn't have a hash for the params, I would just do the params directly, like this:

define monit::monitor($memory = "64m") {
  # ...
}

You could even do:

define monit::monitor::testing($memory = "64m") {
  # ...
}

And create several different defines for each, and use the same template file for it. This way the define is labeled by the name (monit::monitor::testing, monit::monitor::prod, etc), and the parameters are in the define. Have them call a primary define, perhaps, with all the values specified for their normal defaults, or something like that.

I think that would probably be more clear.