I was writing some basic RSpec tests for a puppet module this morning, methodically adding in fixtures and hiera data items to get the module to compile under the spec tests.

Then I hit this error:

Failures:

1) profile_puppet::master supported operating systems profile_puppet::master class without any parameters on redhat 6.4 should compile into a catalogue without dependency cycles
Failure/Error: it { should compile.with_all_deps }
NoMethodError:
undefined method `groups' for nil:NilClass
# ./spec/classes/init_spec.rb:36:in `block (5 levels) in '

Uh oh, that doesn't look good. I did what I always do in such circumstances and googled the error message: puppet NoMethodError: undefined method `groups' for nil:NilClass. The first hit was https://tickets.puppetlabs.com/browse/PUP-1547 which describes my situation completely (I am testing for RHEL 6.4 on OSX).

What's even better is that the ticket was updated 3 days ago with a pull request that fixes the issue. I applied the change locally, it worked perfectly, and I was able to complete my task.

Try doing that with proprietary software.

In his talk at Puppetconf 2013, James Fryman mentioned a blog post by James White which contains a list of guidelines for management which has come to be known as the jameswhite manifesto.

Here’s the same list but unconstrained by a fixed-width text box so you can actually read it. 🙂

Rules

On Infrastructure

  • There is one system, not a collection of systems.
  • The desired state of the system should be a known quantity.
  • The “known quantity” must be machine parseable.
  • The actual state of the system must self-correct to the desired state.
  • The only authoritative source for the actual state of the system is the system.
  • The entire system must be deployable using source media and text files.

On Buying Software

  • Keep the components in the infrastructure simple so it will be better understood.
  • All products must authenticate and authorize from external, configurable sources.
  • Use small tools that interoperate well, not one “do everything poorly” product.
  • Do not implement any product that no one in your organization has administered.
  • “Administered” does not mean saw it in a rigged demo, online or otherwise.
  • If you must deploy the product, hire someone who has implemented it before to do so.

On Automation

  • Do not author any code you would not buy.
  • Do not implement any product that does not provide an API.
  • The provided API must have all functionality that the application provides.
  • The provided API must be tailored to more than one language and platform.
  • Source code counts as an API, and may be restricted to one language or platform.
  • The API must include functional examples and not requre someone to be an expert on the product to use.
  • Do not use any product with configurations that are not machine parseable and machine writeable.
  • All data stored in the product must be machine readable and writeable by applications other than the product itself.
  • Writing hacks around the deficiencies in a product should be less work than writing the product’s functionality.

In general

  • Keep the disparity in your architecture to an absolute minimum.
  • Use Set Theory to accomplish this.
  • Do not improve manual processes if you can automate them instead.
  • Do not buy software that requires bare-metal.
  • Manual data transfers and datastores maintained manually are to be avoided.