If you are writing rspec tests against your controlrepo, specifically your profile module, you need to set up your .fixtures.yml file to reference the other modules in your controlrepo. For example, here’s a list of the modules in the dist directory of a controlrepo:

dist
├── eyaml
├── profile
└── role

If any of the profile modules reference one of the other modules, it needs to be referenced as a fixture or an error is generated that the resource cannot be found:

$ be rspec spec/classes/eyaml_spec.rb

profile::eyaml
  should contain Class[profile::eyaml] (FAILED - 1)
  should contain Class[eyaml] (FAILED - 2)

Failures:

  1) profile::eyaml should contain Class[profile::eyaml]
     Failure/Error: it { should create_class('profile::eyaml') }

     Puppet::PreformattedError:
       Evaluation Error: Error while evaluating a Function Call, Could not find class ::eyaml for build at /home/rnelson0/puppet/controlrepo/
dist/profile/spec/fixtures/modules/profile/manifests/eyaml.pp:15:3 on node build

We can reference these local modules with the symlinks type of fixture, like this:

fixtures:
  symlinks:
    profile: "#{source_dir}"
    eyaml: "#{source_dir}/../eyaml"

The paths must be fully-qualified, so we use #{source_dir}, a magical value available through rspec, to start with the fully-qualified path to the current directory dist/profile. Follow the symlinks type with repositories and other types of fixtures as you normally would.

When you run rake spec or rake spec_prep, these symlinks will be created underneath dist/profile/spec/fixtures/modules automatically for you. Your rspec tests on profiles that include content from these other modules will no longer error with an inability to find the module in question.

$ be rake spec_prep
$ be rspec spec/classes/eyaml_spec.rb

profile::eyaml
  should contain Class[profile::eyaml]
  should contain Class[eyaml]

Finished in 3.39 seconds (files took 1.61 seconds to load)
2 examples, 0 failures

Enjoy!

I’m a strong advocate of creating unit tests for your puppet code with rspec-puppet. I’ve written a number of articles on tests before, so here’s one more.

When you’re testing a class, sometimes there’s an expectation that it’s used alongside another class or resource. But your test is only against your class, so how do you add the other resource to the catalog? As an example, let’s look at the module jlambert121/puppet and how some of the subclasses in the module are tested, specifically puppet::server::install. The top level describe statement ensures that the class puppet::server::install is present. It does not ensure that some of the other classes it relies upon are present.

This is done through the : :pre_condition statements at the beginning of each 2nd level describe, starting on line 3:

  let(:pre_condition) { 'class {"::puppet": server => true}' }

Other describe blocks instantiate the class with different parameters, as needed for the individual test.

In the : :pre_condition, you can add any Puppet DSL you want. I would not suggest going overboard, but including or instantiating another class or a small number of resources can be very helpful. This can be especially helpful with profile classes, where you may want to test behavior when another profile is present, e.g. testing an application profile with multiple webserver profiles.

I did not find the : :pre_condition statement documented anywhere in the rspec-puppet docs, so I hope this helps others discover it.

I recently completed a PE migration from 3.8.4 to 2015.3.3 (puppetserver 2.2.41 and puppet agent 4.3.2). This was a somewhat painful exercise, as we kept running into issues because we had gotten so far behind on upgrades. If you need to perform the same kind of upgrade, I hope this broad-stroke description of the upgrade steps will help you. Before we get to the upgrade, let’s cover some of the pre-requisites.

Release Notes

Always read the release notes first. I am sure I will cover some of the notes below in specific problems we ran into, but there’s a lot on there that we did NOT encounter.

Future Parser

When you get to PE 2015.3.3, you’ll be running Puppet 4. Make sure you have the future parser enabled on your master or agents, by following these instructions. You’ll likely run into at least one issue if you weren’t doing this before. For example, automatic string/array conversions may not work as you expect. Get your code up to par before moving forward.

Continue reading →

If you maintain more than one Puppet module, you’ve probably spent some time aligning changes in your general setup by hand – rspec helpers, Gemfile, Rakefile, your travis config, etc. Once you have a third or a fourth module, you find that does not scale. Thankfully, there’s a great tool to help automate this: Modulesync.

How It Works

We’ll discuss how modulesync works first, so that we understand how to set it up. For instance, to perform a dry run, you would run msync update –noop in a modulesync configuration repo. This creates a directory modules and clones the managed modules into that directory. For each module, it then describes the diffs between the existing contents of the module and the config defined by the modulesync configuration repo. Once the changes are reviewed for accuracy, run msync update -m “Commit message here” and the diffs are applied to the default branch (master) with the commit message specified. By creating a modulesync.yml file, the default namespace and branch can be specified. The use of a different branch name allows you to create a PR to apply the changes.

Continue reading →

I’ve been working recently on migrating to Puppet 4. All the modules I maintain have supported it for a little bit but my master and controlrepo were still on Puppet 3. I slowly hacked at this over the past month and a half when time presented itself and I learned a few things. This post is an assortment of lessons learned, more than a tutorial, but hopefully it will help others going through this effort themselves.

At a high level the process consists of:

• Make sure your code is Puppet 4 compatible via Continuous Integration.
• Find a module that manages Puppet 4 masters and agents. If your current module works with 4, this step is much easier.
• Build a new template or base image that runs Puppet 4.
• Update your controlrepo to work with a Puppet 4 master, preferably with the new puppetserver instead of apache+passenger, again using CI for testing.
• Deploy the new master and then start adding agents.

The biggest lesson I can give you is to perform these changes as 5 separate steps! I combined the last three into a single step and I paid for it. I know better and my shortcut didn’t turn out so well. Especially, do not take your Puppet 3 master down until your Puppet 4 master build tests out okay! Alright, let’s go through some of the steps.

Continue reading →