This post covers the steps of setting up and testing wakame-vdc using packer, chef and test-kitchen with various frameworks. The development environment is Gentoo Linux but wakame-vdc is being deployed to CentOS 6.4 kvm instances. I will be using the vagrant-libvirt plugin described in my previous article “Vagrant-libvirt on Gentoo Linux”. Some of the setup steps are covered in the previous article but have been included here for completeness.

Build CentOS 6.4 x86_64 test image

Packer is not currently available in the base Gentoo distribution so you will have to use my chef overlay to install it. To install packer from my chef overlay you need to install layman, download my repo description, sync it, and add the repository.

$ emerge layman
$ curl https://raw.githubusercontent.com/emiddleton/chef-overlay/master/overlay.xml \
  > /etc/layman/overlays/emiddleton-chef.xml
$ layman -L
$ layman -a emiddleton-chef-overlay

packer is keyword masked so you will need to unmask it before emerging.

$ echo "=dev-util/packer-0.7.5" > /etc/portage/package.keywords/dev-util-packer-0.7.5
$ emerge packer

Now we can use packer to create our machine image. To do this checkout my packer templates and build the CentOS 6.4 x86_64 vagrant-libvirt box as follows

$ git clone https://github.com/emiddleton/packer-templates.git
$ cd packer-templates/CentOS-6.4-x86_64-minimal
$ packer build template.json

Converge Wakame VDC

Install chefdk-omnibus and vagrant as follows

$ pushd /etc/portage/package.keywords/
$ echo "=app-admin/chefdk-omnibus-0.3.5" > app-admin-chefdk-omnibus-0.3.5
$ echo "=app-emulation/vagrant-bin-1.6.5" > app-emulation-vagrant-bin-1.6.5
$ emerge chefdk-omnibus vagrant-bin arp-sk

then install the vagrant-libvirt plugin as your regular user

$ vagrant plugin install vagrant-libvirt

and configure fog to use libvirt as the default provider

1
2
3

default:
  :libvirt_uri: "qemu:///system"
  :libvirt_ip_command: "/sbin/arp -an |grep -i $mac|cut -d '(' -f 2 | cut -d ')' -f 1"

clone and converge the wakame cookbook

$ git clone https://github.com/emiddleton/cookbook-wakame-vdc.git
$ cd cookbook-wakame-vdc
$ kitchen converge default-step-2-centos-64

Test kitchen

The checked out cookbook-wakame-vdc repository contains a .kitchen.yml configuration file shown bellow. This file tells kitchen how to setup the test environment and what tests can be run. Details of the test kitchen configuration file can be found on the chef site¹ (NOTE: this configuration requires the patched version of test-kitchen provided in my overlay to support multiple converge steps)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

---
driver:
  name: vagrant
  provider: libvirt

provisioner:
  name: chef_solo

platforms:
  - name: centos-64
    driver_config:
      box_name: 'centos-6.4'
      box_url: "https://downloads.vortorus.net/vagrant/packer_centos-6.4-x86_64-minimal_libvirt.box"

suites:
  - name: suite_1
    steps:
      - run_list:
        - recipe[wakame-vdc]
        attributes:
      - run_list:
        - recipe[wakame-vdc]
        attributes:
  - name: suite_2
    steps:
      - run_list:
        - recipe[wakame-vdc]
        attributes:
      - run_list:
        - recipe[wakame-vdc]
        attributes:

The suites section contains two test suites named suite_1 and suite_2. You can find the suite_1 tests under the directory test/integration/suite_1_step_[n]/[test type] where n is the step in the converge, and [test type] is the type of test suite (i.e. serverspec, bats, mussel).

Testing with serverspec

The first test suite, suite_1 has a basic serverspec test shown bellow. This is a very basic test suite that just test the relevant server port are being listened on. These sort of are a good way to quickly verify basic expectations about the running system. They can also be useful in uncovering unexpected behavior. I used this test suite to uncover the fact that wakame-vdc was flushing iptables after startup.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

require 'serverspec'

set :backend, :exec

describe "Wakame VDC" do

  describe bridge('br0') do
    it { should exist }
  end

  it "is listening on port 9000" do
    expect(port(9000)).to be_listening
  end

  it "is listening on port 9001" do
    expect(port(9001)).to be_listening
  end

end

run rspec unit tests

DCMGR inclused a number of rspec unit tests. We can run these tests as follows.

$ kitchen login default-step-2-centos-64
$ sudo su -
$ export PATH=/opt/axsh/wakame-vdc/ruby/bin:$PATH
$ cd /opt/axsh/wakame-vdc/dcmgr/
$ bundle exec rspec

Create busser-mussel

Wakame comes with its own shell based test suite called mussel written in bash. To run this we have created a (busser mussel plugin)[https://github.com/emiddleton/busser-mussel] to setup the environment and run the tests. The main code of the plugin is shown bellow. It sets up the musselrc file and runs the instance-clone acceptance test.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# -*- encoding: utf-8 -*-

require "pathname"

require "busser/runner_plugin"

class Busser::RunnerPlugin::Mussel < Busser::RunnerPlugin::Base
  postinstall do
    FileUtils.ln_sf("#{suite_path('mussel')}/musselrc", "/root/.musselrc")
  end

  def test
    inside('/opt/axsh/wakame-vdc/client/mussel/test/acceptance/v12.03/instance-clone') do
      run!('make')
    end
  end
end

1
2
3
4
5

DCMGR_HOST=127.0.0.1
account_id=a-shpoolxx
hypervisor=openvz
image_id=wmi-centos64
RETRY_WAIT_SEC=200

This is still a work in progress. The mussel test runner currently only runs on of the test mussel tests. Other tests appear to require specific network configuration that is not currently setup by this cookbook.