• BlogNav:
• Archive of all posts

Why Your Puppet Module Sucks

Posted: Tue, 29 October 2013 | permalink | 6 Comments

I use Puppet a lot at work, and I use a lot of modules written by other people, as well as writing quite a number of my own. Here’s a brief list of reasons why I might say that your module sucks.

1. You use global variables

This would have to be both the most common idiom that just makes my teeth grind. Defined types exist for a bloody reason. Global variables make it incredibly difficult to reason about what is going to happen when I use a particular global variable (see also “You don’t write documentation”), and I get no feedback if I typo a global variable name. Add in a healthy heaping of “lack of namespacing”, and you’ve basically guaranteed that your module will be loudly cursed.

2. You use parameterised classes

I’ve never managed to work out why parameterised classes even exist. They’ve got all the problems of regular classes, as well as all the problems of types. There was a fantastic opportunity with parameterised classes to fix some of the really annoying things about regular resources, such as doing conflict checking on parameters and only barfing if there was a conflict… but no, if you define the same class twice, even with identical parameters, Puppet will smack you on the hand and take away your biscuit. FFFFFFUUUUUUUUUUUU-

3. You fail at using fail()

Modules are supposed to be reusable. That’s their whole reason for existence. One of the benefits of Puppet is that you can provide an OS-independent interface for configuring something. However, unless you’re some absolute God of cross-platform compatibility, you will only be writing your module to support those OSes or distros that you, personally, care about.

That’s cool – if you don’t know anything about OS X, you probably shouldn’t be guessing at how to support something on that platform anyway. However, when you do have some sort of platform-specific code, for the love of pete, have a default or else clause that calls fail() with a useful and descriptive error message, to indicate clearly that you haven’t included support for whatever environment the module’s being used in. Failing to do this can cause some really spectacular explosions, because the rest of your module assumes that certain things have been done in the platform-specific code, and when it hasn’t… hoo boy.

4. You don’t write documentation

Yes, it isn’t easy to write good documentation. I know that. But without documentation, your module is going to be practically unuseable. So if you don’t have docs, your module is basically useless. Well done, you.

5. You have undeclared dependencies

This also includes declaring your dependencies in a non-machine-parseable manner; I’m not going to grovel through your README for the list of other modules I might need; I have machines to do that kind of thing for me.

If I try to use your module, and it craps out on trying to reference some sort of type or class that doesn’t appear at all related to your module, I will call into question your ancestry, and die a little more inside.

6. You use common packages without even trying to avoid the pitfalls

OK, to be fair this is, ultimately, Puppet’s grand fuckup, not yours, but you at least need to pretend to care…

There is no sane, standardised way in Puppet for multiple modules to install the same package. Let’s say that a module I write needs to have a compiler. So I package { "gcc": }. Then someone else’s module also wants a compiler, so it also package { "gcc": }. FWAKOOM! says Puppet. “What the fuck?” says the poor sysadmin, who just wanted both a virtualenv and an RVM environment on the one machine.

Basically, using packages is going to make your module suck. Does that mean that this makes wide distribution of a large repository of modules written by different people nigh-on impossible? Yes. Fantastic.