Puppet Tips&Tricks: debugging includes and inheritance
This is the second post in a series of mine, describing some of the methods I use while developing our new Puppet modules. Read the first post in the series here: Variable variables.
Even though there are lots of interesting tools these days for debugging running code and even scripted code, I still seem to grab at the old method of printing random stuff in between my code. Especially when debugging my puppet modules. Some stuff to keep in mind when you also do this:
- All functions (like err, debug or warning) are server side only. This means you’ll have to search the log on your puppetmaster if you want to see the output from those.
- If you want to have output on your client, which is usually more convenient for me, use the notify resource. Use it like so:
notify { "Yes, we really arrived at this class.":; }
Which will output on the client something like this:
notice: //nagios::client/Notify[Yes, we really arrived at this class.]/message: defined 'message' as 'Yes, we really arrived at this class.'
Which at least shows you that a certain class is loaded. - Keep in mind that you can also include variables in the string you add! Very helpful to see if you get what you were expecting. I use that a lot to see if inline_templates give the output I expect.
Hope this helped someone!
Puppet Tips&Tricks: Variable variables
[Repost of my post on the Kumina blog.]
This is the first post in a series of mine, while I’m reinventing our puppet modules. Puppet is the tool we use to maintain most machines in our care. We make it a point to share our modules as much as possible, so others might benefit from them.
Today I was working on our kbp_firewall module, which sets some variables that other modules can use via qualified variables. We differentiate between “protected”, “public” and “management” network interfaces on each host. These are always separate (virtual) interfaces, to make our life a little easier. I wanted to make both the interface and the IP address for these easily available, but I wanted most of it to happen automagically after puppet has determined which interface is connected to which network. I wanted to use the facter fact $ipaddress_(interface name), which is created for each interface, like for example $ipaddress_eth0.
Currently, there’s no way to use something like $ipaddress_${interface}, although I’ve been told on the #puppet IRC channel that this will be implemented in the next major version. So I had to create a more hackish solution. Inline_template to the rescue!
What I currently do:
$protected_ip = inline_template("<%= ipaddress_${protected_if} %>")
This will probably work in future versions too, so I feel confortable implementing it like this. Once we’ve fully switched to the next major release, I can slowly work through the code to make it all a bit better readable.
Hope this helps someone!
