Reviving veewee after Vagrant 1.1

Recently, Mitchell Hashimoto released a major rewrite of Vagrant, the tool that lets you build, provision, and rebuild virtualized development environments at the click of a button. While the rewrite is great — it has many new features, chief amongst them the ability to use virtualization providers other than VirtualBox — it was a major architectural change, and this broke many tools that work with Vagrant. One of them is veewee, a popular tool from Patrick Debois that allows anyone to rebuild fresh Vagrant boxes. Here’s how I fixed my veewee installation for now.

Vagrant 1.1 represents a major rewrite. While the vagrant command-line tool remains the same, the package format changes significantly. Vagrant 1.1.x is only being distributed as an “omnibus” package, which bundles Ruby and all the Rubygems that Vagrant needs. (In another post, we can argue about whether the trend towards omnibus Ruby installers is a good one or not.) Vagrant 1.1 also introduces a new plugin architecture, and developers hoping to add functionality to Vagrant must rewrite their plugins to be conformant with the new API. Some of the developers who have already rewritten their plugins include Jamie Winsor, the author of Berkshelf, and Cassiano Leal, the author of vagrant-butcher (to clean up test node and client objects from Chef when using a Chef Server provisioner).

Veewee, however, presents a special challenge. Veewee depends on Vagrant being available as a Rubygem, a format that Mitchell is no longer distributing officially. To solve this, we need to use Bundler to create a Gem directly from Git, and manage some of Veewee’s other bleeding-edge dependencies.

If you haven’t guessed already, this is a set of technologies that is in enormous flux, and my instructions here merely provide for a workaround until a more elegant solution comes about (if it does). That said, let’s write ourselves a Gemfile that’ll let us successfully install and run Veewee, based on Patrick’s own Gemfile:

source "https://rubygems.org"

gem "veewee", :git => 'https://github.com/jedi4ever/veewee.git', :ref => '333ffcaba291a3cca9a54ebb9bf48ef534d60cfd'

group :windows do
  gem "em-winrm", :git => 'https://github.com/hh/em-winrm.git', :ref => '31745601d3'
  gem "log4r"
end

group :test do
  gem "rake"
  gem "vagrant", :git => 'https://github.com/mitchellh/vagrant.git', :tag => 'v1.1.5'
  #gem "chef"
  #gem "knife-windows"
end

I’m not sure if all the groups are necessary, but I’m not familiar enough with Bundler to know what they’re used for.)

You’ll notice a couple key things here. First, I’m tying veewee itself to a particular commit hash – this points to HEAD at the time of writing, but since the project is under heavy development, there will be more commits after this. The reason I’m pointing to GitHub for veewee itself is because the version on Rubygems.org, 0.3.7, is quite old and a new one hasn’t been released for a while.

Second, in group :test, the Vagrant gem points to Mitchell’s GitHub repository with a particular tag attached to it — this represents the source code of the currently-released version, 1.1.5.

Now that we have a Gemfile set up, we can run bundle install to install all these Gems on our system, including the bleeding-edge ones (which won’t show up when you type gem list, but are nonetheless on your system).

To test, let’s try to build a CentOS 6.4 box. Veewee’s convention is that box definitions live in a definitions directory, so let’s make a directory called definitions/CentOS-6.4-x86_64-minimal and copy the files out of Patrick’s master repo into there.

Now, we can try to build the box with the command

bundle exec veewee vbox build CentOS-6.4-x86_64-minimal

(assuming we’re going to use VirtualBox to build it). If this works, you should get a lot of output as veewee brings up a new VirtualBox machine, automates the operating system installation, and installs Chef, Puppet, and makes a few other system customizations to make it conform to the Vagrant box interface. Once done, you can type

bundle exec veewee vbox validate CentOS-6.4-x86_64-minimal

to run some basic tests against that box to ensure it meets that interface.

Finally, once we’re satisfied, we can then export this box using

bundle exec veewee vbox export CentOS-6.4-x86_64-minimal

Voilà, we have a box file we can use with VirtualBox and Vagrant in the usual fashion.

To summarize: the current interactions between Vagrant 1.1 and some older plugins are still shaky, but developers are working hard to adapt to the new plugin architecture. (Another example where heavy development is occurring is on the vagrant-windows plugin, which is still not compatible with Vagrant 1.1.) Until these problems are worked out, workaround procedures like the above, for veewee, are necessary.

Later in the week, I’ll talk about how to get a local Chef cookbook development environment set up using Vagrant 1.1 and Berkshelf. Stay tuned.