{"id":3468,"date":"2011-11-02T17:55:41","date_gmt":"2011-11-03T01:55:41","guid":{"rendered":"http:\/\/www.chesnok.com\/daily\/?p=3468"},"modified":"2012-03-26T02:21:10","modified_gmt":"2012-03-26T10:21:10","slug":"puppet-faces-defaults-and-puppet-node-clean","status":"publish","type":"post","link":"https:\/\/www.chesnok.com\/daily\/2011\/11\/02\/puppet-faces-defaults-and-puppet-node-clean\/","title":{"rendered":"Puppet Faces: defaults and ‘puppet node clean’"},"content":{"rendered":"

Puppet Faces are an extendable API for tricking out your Puppet instances. (“Faces” is just short for “Interfaces”.) Just a couple days ago I wrote about my survey of puppet + ec2 provisioning tools<\/a>.<\/p>\n

The problem I’m trying to solve, which I don’t feel like I’ve solved well, is how to give a type to a new system at bootstrap time, without using DNS. The type variable maps to a node manifest group, and determines the personality of a host – is it a database, webserver or development instance?
\n
\nWhat I’d like to do is pass a type to puppet at install time and have the puppetmaster and the agent remember that mapping between host and type. <\/p>\n

I did it with a really simple Facter plugin, install scripts named by type (passed in to puppet node install<\/code>), and a file created by the install script in \/etc\/puppet<\/code>.<\/p>\n

Then, I wanted to be able to see which hosts were configured with which install type. Facter was aware of the type, so this seemed like it should be pretty easy…<\/p>\n

I wrote a quick and dirty Face that pulls information out of $varlib\/nodes\/*.yaml<\/code> on the puppet master. I imagine there are better ways to do this, but in the absence of documentation or someone to tell me not to do this, I forged ahead!<\/p>\n

There were two things that I spent quite a bit of time chewing on before figuring it out: <\/p>\n

    \n
  1. If you want to make an :action<\/code> in your Face the default, you just add default<\/code> in the body of your :action<\/code> block. I had to dig through a few cloudpack files before I found it!<\/li>\n
  2. If you are creating and terminating hosts frequently, you may end up with a bunch of certs and other annoying metadata laying around. To clean it up, the Puppet Node Face has a command you can run:
    \n
    \n# puppet node clean [hostname]
    \n<\/code><\/p>\n

    You’ll probably need to be the user that’s running puppet for this to work — it affects things that the puppetmaster owns in $varlib<\/code>. <\/p>\n

    If you’re doing this with code, it’s:
    \n
    \nPuppet::Face[:node, :current].clean('hostname')
    \n<\/code>\n<\/li>\n<\/ol>\n

    I put a little patch<\/a> into a recent version of cloudprovisioner that invokes clean during a terminate. It’s quick and dirty, and only for AWS. <\/p>\n

    The resources I’ve found useful are: <\/p>\n