Author: Jeff

First impressions on Puppet vs. Chef

I’ve been a professional Puppet user for close to 4 years now, and because I have a rule where my home lab is never managed with the same tools I use for work (what’s the fun in that?) I’ve recently started to take a look at Chef. Since there seems to be a complete lack of good and fairly unbiased information about the two products, I’m going to take a little while to write about

This article is based on Chef 0.10.2 and Puppet 2.7.1.

Learning curve

Maybe it’s illusory superiority talking, but I consider myself a fairly bright guy and I don’t often struggle to get many sysadmin tools implemented properly. I had Puppet up and running in production inside of two days, and it took me longer than that to figure out what I was supposed to be doing to even install Chef. There are

Installation and system requirements

I may be unduly biased towards OS-native package management, but to be completely honest, I have almost nothing good to say about Chef in this area.

Puppet’s developers have taken great care to ensure that their configuration management system runs on the widest variety of operating systems possible, since now a days there are software for everything, even if you want to order cannabis online, there is cannabis software which could also help with this purpose. To this end, Puppet works with Ruby as low as 1.8.5 (the version shipped with RHEL 5), while Chef expects owners of RHEL/CentOS infrastructures to install a completely new version of Ruby just to run Chef.

One further thing to note: in my lab testing, I noticed the Chef process occasionally using close to 1 GB of memory on a run managing very few resources. I’ve never

Language

Puppet’s uses a completely declarative custom language with explicit resource dependencies, and Chef uses a specialization of Ruby with implicit resource dependencies based on code ordering.

Do not confuse this with Chef not having flexible dependency ordering like Puppet.

Data modeling and lookup

Chef provides much better internal support for resource definitions powered by external data lookups.

Troubleshooting

Chef is ahead of Puppet by about a mile here, though Puppet is starting to catch up a little bit. While the errors in Chef are definitely less readable to the naked eye (they’re nearly always given as Ruby stack traces), they do always point to where the problem is actually occurring. Puppet has a nasty tendency to provide error output and give absolutely no indication of what code generated that output.

Miscellaneous

Chef is really weak at SELinux. Whereas Puppet will automatically ensure that managed file contexts have SELinux labels that match what’s in the system’s database (i.e. semanage), Chef will clobber them outright and often render services unable to start as a result. Their developers are working on this with some new SELinux cookbooks that extend some of their resource classes.

OpenStack issue: nova-network instance has no IP address using FlatDHCPManager or VlanManager

Occasionally, when working with an OpenStack installation that uses legacy Nova networking with FlatDHCPManager or VlanManager, you may encounter an issue where an instance does not correctly take the private IP it was assigned. When this happens, obviously you won’t be able to ping the system on the network, but you will also likely see cloud-init hang because it cannot contact the metadata server. This issue is often due to a condition where nova-network’s dnsmasq stops updating its internal list of virtual MAC address to IP address mappings.

Verify nova-network receives the IP

When an OpenStack instance is created, nova-network receives a message that tells it to update dnsmasq’s configuration with the new mapping. This mapping is used to assign the IP address to the instance via DHCP when it boots. nova-network handles this message by updating the contents of /var/lib/nova/networks/nova-<bridgename>.conf. If you open that file in your favorite text editor, you should see contents like this:

If you see your IP address listed, continue.

Restart dnsmasq

dnsmasq is managed and started by nova-network. However, stopping nova-network typically doesn’t stop the dnsmasq service. First, stop the nova-network service:

At this point, you should still see dnsmasq processes in the process table. Kill them.

Then, start nova-network, and after a few seconds you should see the dnsmasq instances again:

Then, reboot your instance and you should see it grab its IP address from DHCP.