I am finch.

I do things and complain.
That is all.



I’ve been involved with the Puppet community for the last 6 or so years. It’s been great to be involved with such a great group of people, and I feel that I’ve been able to contribute a lot to benefit the community as a whole.

But as the years have passed, the work that started as a fun hobby has started to weigh on me. I have been the sole maintainer for many projects, have helped maintain many more, and have frequently been asked to help with yet even more projects. At one point I could expect to see emails for one to two new GitHub issues a day, and conversations on several more. Simply keeping up with this volume of email alone is exhausting. Actually keeping up with fixing bugs, adding features, merging pull requests, and providing support has proved overwhelming.

I’m tired. I’m probably more than a little burned out. I’m unable to keep up with issues, and even if I could I don’t think it would do much good. It’s very important to me to provide a welcoming environment for people, and I don’t think I’m capable of providing the level of positivity and energy needed to do that.

» Read full post

r10k 1.4.0


It is my distinct pleasure to announce that r10k 1.4.0 has been unleashed upon the world. As always you can download the gem from rubygems.org and check out the release notes in the changelog, or you can continue on for witty banter about the release.

R10k 1.4.0 doesn’t boast a large number of major new features, but instead focuses on smaller bugfixes and feature improvements that make r10k more consistent and usable. A lot of the changes are actually under the hood, where they won’t directly affect users but will provide the scaffolding for a number of future improvements.

Changes to the CLI

One of the nifty new features of r10k is the ability to display the expected and actual versions of your installed modules. Before r10k 1.4.0, the r10k deploy display -p command would show the environments and modules, but it would only show only the intended module versions and not the version of the installed modules.

» Read full post

Opiates and Testing


After more than a year off from blogging I managed to wander into my blog drafts folder and found a mostly finished blog post from past ages. Perhaps an old post brought to life will kickstart new blog posts so without further ado, here is a tale of painkillers, programming, and pontifications.

My discovery of unit testing and test driven development was a happy accident due to desperation and vicodin.

In my second year of college I was took a computer science course on algorithms and data structures. All was going well until I was in a bad rock climbing accident, fell a good 30 feet or so, and broke my right foot in about 10 places. (Approximately. The doctors lost count of all the fractures). I tried soldiering on in that algorithms class, but I discovered after the fact that vicodin and programming DO NOT MIX. Things got ugly when I tried writing a binary search tree. I would happily bash out code and nested if statements, try to run it, and watch my program spin off in an endless loop. It turns out that in my attempt to write a binary search tree, I had invented a whole new data structure - the binary wreath. It was bad.

» Read full post

The Puppet RAL: Types, Parameters, and Properties


This is the second post on a series on the Puppet RAL.

The RAL needs to be able to model any sort of thing you would want to manage. Because of this it’s broken into a number of different classes to be able to model any sort of resource you could need. This blog post is going to discuss the puppet Type, Parameter, and Property classes and what they do.


A Puppet Type represents a category of things you can manage. Things like users, services, files, and so forth are examples of common types. Types provide the structure for managing things and define what you can do with them.

The Type
service { 'my-service':
  ensure  => running,
  restart => '/usr/local/bin/restart-my-service',

An important detail is that Types are (mostly) abstract, and only define what instances of that Type can do. This is one of the killer features of the RAL for a number of reasons.

First off, it’s trivial to extend the core behavior of Puppet. If you want to add support for a new platform it’s not necessary to add extensions to core Puppet; you can implement a provider for that type and use it immediately.

» Read full post

The Puppet RAL: An Introduction


The Puppet RAL is one of the main parts of Puppet that people use on a daily basis. The RAL is how system state is actually inspected and enforced by Puppet, it’s where most extensions to Puppet are added, and it’s one of the parts of Puppet that really set it apart.

Unfortunately, the RAL is a little lacking on the side of documentation and explanation. The RAL provides a lot of powerful functionality but unless you’ve been digging through that code on a regular basis, it can prove hard to make full use of the RAL.

As of late the state of developer documentation has been improving. Puppet 3.1 added much improved inline documentation to a lot of the code base and covered a lot of the RAL, which is a welcome improvement. In addition Dan Bode and Nan Liu wrote the excellent Types and Providers book, which is arguably the best reference to the RAL to date.

» Read full post

View all blog entries