A couple of tips for writing Puppet manifests

Tom Moertel — Thu, 15 Nov 2007 02:30:00 -0500

I recently started using Puppet to automate my server-build processes. The basic idea behind Puppet is that you create “manifests” that declare a directed graph of “resources” that represents the desired state of your machines. Puppet-managed machines on your network then query a master server to obtain the latest copy of the graph, which they then reconcile with their current states to make whatever changes are necessary to bring themselves up to date.

For the most part, everything works well. I have encountered a couple of snags when writing manifests, however, so I’m going to explain them here as reminder until I get the time to fix them in the Puppet code and send patches upstream.

First, don’t use hyphens in class names. While hyphens are legal in class names, they are not allowed in qualified variables, thus variables defined within hyphen-named classes are inaccessible from the outside world.

Second, and this one is both tricky and important, Puppet handles prerequisites for definitions by silently passing those prerequisites on to all of the resources within the definitions. Definitions, in effect, don’t really have their own prerequisites, they just pass them on to their children. But – and here’s the problem – if those child resources declare their own prerequisites, those prerequisites will overwrite the passed-on prerequisites, effectively causing them to be ignored.

This problem bit me hard when trying to create a definition for installing Ruby Gems from a local cache of gems:

define local_gem($gem) {
    $path = "/var/local/local-gems/$gem" 
    file { $path:
        ensure  => present,
        source  => "puppet://puppet/files/gems/$gem",
        require => File["local-gems-dir"],
        owner   => root,
        group   => root,
        mode    => 0664,
    }
    package { $title:
        ensure   => installed,
        provider => "gem",
        require  => [ Package["rubygems"], File[$path] ],
        source   => $path,
    }
}

The intent was to be able to declare a local gem like so:

local_gem { "sqlite3-ruby":
    gem     => "sqlite3-ruby-1.2.1.gem",
    require => Package["sqlite-devel"]
}

Thus the “sqlite3-ruby” local gem has the single prerequisite of the “sqlite-devel” package – or at least that’s what I expected. What happened on deployment was that the prerequisite was ignored because when it was passed on to the inner file and package resources, those resources had their own require parameters, and those parameters overwrote the passed-on prerequisite.

The work-around is somewhat hacky. I augmented the definition with a do-nothing resource that has no require parameter of its own. This resource does nothing but capture the passed-on prerequisites. Then I made all of the other resources in the definition include the do-nothing resource as one of their prerequisites. Thus they are made to inherit the passed-on prerequisites.

My final definition looks like this:

define local_gem($gem) {

    # dummy exec to propagate requires from local_gem
    exec { $name: command => "/bin/true" }

    $path = "/var/local/local-gems/$gem" 
    file { $path:
        ensure  => present,
        source  => "puppet://puppet/files/gems/$gem",
        require => [ Exec[$name], File["local-gems-dir"] ],
        owner   => root,
        group   => root,
        mode    => 0664,
    }
    package { $title:
        ensure   => installed,
        provider => "gem",
        require  => [ Exec[$name], Package["rubygems"], File[$path] ],
        source   => $path,
    }
}

Notice how the file and package resource both require the dummy exec resource. That’s the trick that allows them to require the prerequisites passed on from the local_gem definition.

It’s not pretty, but it works. See this email on the puppet-users mailing list for more on the problem.

Tom Moertel's Weblog: A couple of tips for writing Puppet manifests

A couple of tips for writing Puppet manifests