Kitchen::Vagrant

A Test Kitchen Driver for Vagrant.

This driver works by generating a single Vagrantfile for each instance in a sandboxed directory. Since the Vagrantfile is written out on disk, Vagrant needs absolutely no knowledge of Test Kitchen. So no Vagrant plugin gem is required.

Requirements

Vagrant

A Vagrant version of 1.1.0 or higher is required for this driver which means that a native package must be installed on the system running Test Kitchen.

Note: If you have previously installed Vagrant as a gem (a version prior to 1.1.0), this version may be resolved first in your PATH. If you receive an error message that Vagrant is too old despite having installed Vagrant as a package, you may be required to uninstall the gem version or modify your PATH environment. If you require the vagrant gem for older projects you should consider the vagrant-wrapper gem which helps manage both styles of Vagrant installations (background details).

Virtualbox and/or VMware Fusion/Workstation

Currently this driver supports VirtualBox and VMware Fusion/Workstation. Virtualbox is free and is the default provider for Vagrant.

VirtualBox package

If you would like to use VMware Fusion/Workstation you must purchase the software from VMware and then must also purchase the Vagrant VMware plugin.

Vagrant VMware Plugin

VMware Fusion

VMware Workstation

Vagrant Berkshelf Plugin

If a Berksfile is present in your project's root directory, then this driver will check to ensure that the vagrant-berkshelf plugin is installed.

If your project doesn't use Berkshelf then this check will be skipped.

Note: Prior to release 1.2.0, then name of the vagrant-berkshelf gem was berkshelf-vagrant. This driver no longer checks for the existance of berkshelf-vagrant, so upgrading this Vagrant plugin is recommended.

Installation and Setup

Please read the Driver usage page for more details.

Default Configuration

This driver can determine the Vagrant box name and download URL for a select number of platforms. Currently, the following platform names are supported:

---
platforms:
- name: ubuntu-10.04
- name: ubuntu-12.04
- name: ubuntu-12.10
- name: ubuntu-13.04
- name: centos-5.9
- name: centos-6.4
- name: debian-7.1.0

This will effectively generate a configuration similar to:

---
platforms:
- name: ubuntu-10.04
  driver_config:
    box: opscode-ubuntu-10.04
    box_url: https://opscode-vm-bento.s3.amazonaws.com/vagrant/opscode_ubuntu-10.04_provisionerless.box
- name: ubuntu-12.04
  driver_config:
    box: opscode-ubuntu-12.04
    box_url: https://opscode-vm-bento.s3.amazonaws.com/vagrant/opscode_ubuntu-12.04_provisionerless.box
- name: ubuntu-12.10
  driver_config:
    box: opscode-ubuntu-12.10
    box_url: ...
# ...

Configuration

box

Required This determines which Vagrant box will be used. For more details, please read the Vagrant machine settings page.

There is no default value set.

box_url

The URL that the configured box can be found at. If the box is not installed on the system, it will be retrieved from this URL when the virtual machine is started.

There is no default value set.

provider

This determines which Vagrant provider to use when testing and should match the provider name in Vagrant. For example, to use VMware Fusion the provider should be vmware_fusion. Please see the docs on providers for further details.

By default the value is unset, or nil. In this case the driver will use the Vagrant default provider which at this current time is virtualbox

customize

A Hash of customizations to a Vagrant virtual machine. Each key/value pair will be passed to your providers customization block. For example, with the default virtualbox provider:

driver_config:
  customize:
    memory: 1024
    cpuexecutioncap: 50

will generate a Vagrantfile configuration similar to:

Vagrant.configure("2") do |config|
  # ...

  config.vm.provider :virtualbox do |virtualbox|
    virtualbox.customize ["modifyvm", :id, "--memory", "1024"]
    virtualbox.customize ["modifyvm", :id, "--cpuexecutioncap", "50"]
  end
end

Please read the Vagrantfile configuration page for more details.

By default, each Vagrant virtual machine is configured with 256 MB of RAM. In other words the default value for customize is {:memory => '256'}.

dry_run

Useful when debugging Vagrant CLI commands. If set to true, all Vagrant CLI commands will be displayed rather than executed.

The default is unset, or nil.

network

An Array of network customizations for the virtual machine. Each Array element is itself an Array of arguments to be passed to the config.vm.netork method. For example:

driver_config:
  network:
  - ["forwarded_port", {guest: 80, host: 8080}]
  - ["private_network", {ip: "192.168.33.33"}]

will generate a Vagrantfile configuration similar to:

Vagrant.configure("2") do |config|
  # ...

  config.vm.network :forwarded_port, guest: 80, host: 8080
  config.vm.network :private_network, ip: "192.168.33.33"
end

Please read the Vagrant networking basic usage page for more details.

There is no default value set.

use_vagrant_provision

Determines whether or not this driver will use a vagrant provision shell out in the converge action. If this value is falsey (nil, false) the behavior from Kitchen::Driver::SSHBase will be used, bypassing the Vagrant Chef solo provisioner. If this value is truthy, a vagrant provision will be used.

The default is unset, or nil.

use_vagrant_berkshelf_plugin

Determines whether or not this driver will use the vagrant-berkself Vagrant plugin to assemble cookbook dependencies. If this value if falsey (nil, false) then the driver will skip the vagrant-berkshelf dependency check and not activate the plugin in the rendered Vagrantfile. If this value is truthy the opposite behvior will be used.

The default is unset, or nil.

synced_folders

Allow the user to specify a collection of synced folders for on each Vagrant instance.

The default is an empty Array, or []. The example:

driver_config:
  synced_folders: [["/Users/mray/ws/cookbooks/pxe_dust/.kitchen/kitchen-vagrant/opt/chef", "/opt/chef"]]

will generate a Vagrantfile configuration similar to:

Vagrant.configure("2") do |config|
  # ...

  c.vm.synced_folder "/Users/mray/ws/cookbooks/pxe_dust/.kitchen/kitchen-vagrant/opt/chef", "/opt/chef"
end

require_chef_omnibus

Determines whether or not a Chef Omnibus package will be installed. There are several different behaviors available:

• true - the latest release will be installed. Subsequent converges will skip re-installing if chef is present.
• latest - the latest release will be installed. Subsequent converges will always re-install even if chef is present.
• <VERSION_STRING> (ex: 10.24.0) - the desired version string will be passed the the install.sh script. Subsequent converges will skip if the installed version and the desired version match.
• false or nil - no chef is installed.

The default value is unset, or nil.

username

This is the username used for SSH authentication if you would like to connect with a different account than Vagrant default user.

If this value is nil, then Vagrant parameter config.ssh.default.username will be used (which is usually set to 'vagrant').

The default value is unset, or nil.

ssh

A Hash of customizations to Vagrants SSH settings used to access your box. Please read the [vagrantfile_ssh_settings][Vagrant SSH Settings] page for more informations.

Available settings are:

• username
• host
• port
• private_key_path
• forward_agent
• forward_x11
• guest_port
• keep_alive
• max_tries
• shell
• timeout

There is no default value set.

The Example:

driver_config:
  ssh:
    forward_agent: true

Will enable agent forwarding over SSH connections.

The "ssh.username" setting will get overwritten by the "username" setting when set. In this example:

driver_config:
  username: joe
  ssh:
    username: vagrant

the effective username setting will be "joe".

Development

• Source hosted at GitHub
• Report issues/questions/feature requests on GitHub Issues

Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:

1. Fork the repo
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Added some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

Authors

Created and maintained by Fletcher Nichol (fnichol@nichol.ca)

License

Apache 2.0 (see LICENSE)