using Vagrantfile with test-kitchen

[Arthur autohandle]

i have a Vagrantfile that starts a Virtualbox:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# http://cjlarose.com/2014/03/08/run-docker-with-vagrant.html

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  #config.vm.box = "precise64"
  #config.vm.box_url = "http://files.vagrantup.com/precise64.box"
  config.vm.box = "opscode-ubuntu-13.10"

  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  config.vm.box_url = "
http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-13.10_chef-provisionerless.box
"

  config.ssh.forward_agent=true
  config.ssh.forward_x11=true

  config.vm.provision :shell, :inline => "sudo apt-get update"
  config.vm.provision :shell, :inline => "sudo apt-get install -y curl"
  # install docker
  config.vm.provision :shell, :inline => "curl https://get.docker.io/ubuntu/| sudo sh"

....................more..............................

it doesn't do much - but it is running - and  i am ready to use
test-kitchen. i tried to follow the directions, and i didn't have any tests
yet - but when i used bundle to run "kitchen verify", it started up some
other vm from the yaml file - so i used my "Learn Chef" book and tried to update the yaml file to point
to my idea of what the vm should be:

platforms:
  - name: opscode-ubuntu-13.10
    driver:
       box_url:
http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-13.10_chef-provisionerless.box

but, when it started up - kitchen still had it own idea of what the vm name and the url of the vm
should be:

Software-Engineerings-MacBook-Pro:ubuntuDocker david$ bundle exec kitchen
verify
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-opscode-ubuntu-1310>...
       Bringing machine 'default' up with 'virtualbox' provider...
       ==> default: Box 'opscode-opscode-ubuntu-13.10' could not be found.
Attempting to find and install

[Mischa Taylor]

Use the box: directive to specify the vagrant name.  It maps to the config.vm.box directive in the Vagrantfile - the name: directive does not.  Example .kitchen.yml follows:

--- driver:   name: vagrant provisioner:   name: chef_solo

platforms:   - name: opscode-ubuntu-13.10     driver:

box: opscode-ubuntu-13.10       box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-13.10_chef-provisionerless.box suites:   - name: default     run_list:     attributes:

Note the with the addition of the box: directive, the vagrant name matches accordingly:

$ bundle exec kitchen create

-----> Starting Kitchen (v1.2.1)

-----> Creating <default-opscode-ubuntu-1310>...

       Bringing machine 'default' up with 'virtualbox' provider...

       ==> default: Box 'opscode-ubuntu-13.10' could not be found. Attempting to find and install...

[Testing with Chef]

RE: Arthur Autohandle

ok - that sort of worked - stopping another box download:

Software-Engineerings-MacBook-Pro:ubuntuDocker david$ bundle exec kitchen verify

-----> Starting Kitchen (v1.2.1)

-----> Creating <default-opscode-ubuntu-1310>...

       Bringing machine 'default' up with 'virtualbox' provider...

       ==> default: Importing base box 'opscode-ubuntu-13.10'...

       ==> default: Matching MAC address for NAT networking...

       ==> default: Setting the name of the VM: default-opscode-ubuntu-1310_default_1398613232856_83690

i have a vagrant vm already running: ubuntu13-10-docker

that i want to test, i didn't want to start a new vm, so i changed the name parameter in the yml file to: ubuntu13-10-docker

platforms:

  - name: ubuntu13-10-docker

    driver:

       box: opscode-ubuntu-13.10

       box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-13.10_chef-provisionerless.box

Software-Engineerings-MacBook-Pro:ubuntuDocker david$ bundle exec kitchen verify

-----> Starting Kitchen (v1.2.1)

-----> Creating <default-ubuntu13-10-docker>...

       Bringing machine 'default' up with 'virtualbox' provider...

       ==> default: Importing base box 'opscode-ubuntu-13.10'...

       ==> default: Matching MAC address for NAT networking...

       ==> default: Setting the name of the VM: default-ubuntu13-10-docker_default_1398613410107_68802

       Skipping Berkshelf with --no-provision

       ==> default: Fixed port collision for 22 => 2222. Now on port 2200.

       ==> default: Clearing any previously set network interfaces...

       ==> default: Preparing network interfaces based on configuration...

but, it started up another vm anyway - is it possible to test the vagrant vm that i already have running or do i always need to start a new one for testing?

On Saturday, April 26, 2014 7:04:43 AM UTC-7, Arthur autohandle wrote:

[Mischa Taylor]

There's no good way that I know of to make Test Kitchen to be able to reuse an existing vagrant VM outside of its control, short of writing a new plugin to support this functionality or extending Test Kitchen via the Rakefile trick I showed in another post.

As we covered in the class, while you do have to spin up a new VM once in Test Kitchen, you don't have to spin up a new VM every time you run tests.  That VM can be reused with the "kitchen converge"/"kitchen verify" commands (as opposed to "kitchen test", which will automatically destroy the VM and create it clean).  This is definitely recommended while you are developing a cookbook, as you don't want to have to wait for a VM to spin up every time your run your tests.  Just before you are "done done" do a final "kitchen test" to verify that everything works on a clean setup.

[Arthur autohandle]

i don't mind using the "kitchen converge"/"kitchen verify" commands - although i have forgotten them already, i'll have to
review my notes - let me do that.

what is still worrying me is: will the "kitchen converge"/"kitchen verify" commands use my vagrant file? i have config.vm.provision and config.vm.provider blocks in my vagrant file - it looks to me like kitchen is spinning up its own idea of what the vagrant file should be.

thanks for helping me.

[Mischa Taylor]

Well, the idea is that when you use Test Kitchen you will no longer be using the Vagrantfile directly.  Test Kitchen is intended to be a superset of a Vagrant, supporting metal, cloud, virtual machines and containers.  Though it does reuse & leverage vagrant via the kitchen-vagrant provider when you use it in that mode.

You can also pass through any custom Vagrantfile settings in your .kitchen.yml if neededed.  See the answers to a similar thread on the topic here: https://groups.google.com/forum/#!topic/testing-with-chef/KhneNNuC7yw

And of course since Test Kitchen natively supports Chef, you can use it for the Chef-calling bits via suites.

I used to be a heavy user of Vagrant directly, now I've found myself using Test Kitchen almost exclusively instead - because it has all these extra capabilities, plus tight integration with Chef (not like they force us to use these tools at Chef either).  In particular because I've switched the bulk of my Linux work to Docker, I love being able to spin up containers and say, Windows VMs side by side with Test Kitchen.  YMMV but it is basically an either/or decision, as Test Kitchen does not currently provide easy integration with existing Vagrantfiles.

[Arthur autohandle]

shoot! i missed that (big bullet point) in the class - i may be an embarrassed remedial student. before class, i had been following the tutorial:
http://misheska.com/blog/2013/06/16/getting-started-writing-chef-cookbooks-the-berkshelf-way/
i didn't get to the final part about kitchen, i only practiced the 2 vagrant parts - with some branching out on my own. i came to class (with the mistaken impression) that the kitchen part was just an extension of the vagrant parts.

would you mind, let me ask a beginner question - and get reoriented. i assume to only use chef kitchen, i am going to need to translate my Vagrantfile into chef and kitchen:

o i see that for:
    config.vm.provision :shell - i can use chef: script

o for config.vm.provider :virtualbox - i can use:
    driver:
        name: vagrant
o for config.vm.provider :aws - i can use:
    driver:
        name: kitchen-ec2
o i will have 2 yml files? 1 for virtualbox and 1 for ec2 - can i select yml files from the command line or will i put them in separate directories? i couldn'r tell from the help line if the CONFIG file was the yml file.

o i'm not sure where to put my ssh stuff:
    config.ssh.forward_agent=true
    config.ssh.forward_x11=true

o i put my run list:

    config.vm.provision :chef_solo do |chef|
      # the sublime editor
      chef.add_recipe "apt"
      chef.add_recipe "sublime-text::default"
      chef.add_recipe "sublime-text::apt-file"

      # add gui
      config.vm.provider :virtualbox do |vb, override|
      #puts("provision-provider-vb: <#{vb}>, vb.gui: <#{vb.gui}>")
      if vb.gui
          then
            chef.add_recipe "sublime-text::install-ubuntu-desktop"
          end
      end
    end

   in the yml:

   suites:

      - name: default

      - run_list: apt,sublime-text::default,sublime-text::apt-file

o can i have conditional code in the yml so that if the gui is installed, i can add the desktop? or do i create conditional code with separate yml files - or can i add recipes to the run list in the chef code?

sorry to have gotten so confused-

--
You received this message because you are subscribed to the Google Groups "Testing with Chef" group.
To unsubscribe from this group and stop receiving emails from it, send an email to testing-with-c...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mischa Taylor]

I'll answer the question in parts as this is an involved question.  In Test Kitchen parlance, it is possible to assign different drivers to instances in the same .kitchen.yml file.  Here's an example of kitchen list output where I've defined one instance that uses the kitchen-vagrant driver and another that uses the kitchen-ec2 driver (they could use the same OS, but I'm using different OSes for illustrative purposes):

Instance             Driver   Provisioner  Last Action default-ubuntu-1310  Vagrant  ChefSolo     <Not Created> default-centos-65    Ec2      ChefSolo     <Not Created>

All you have to do is specify at least specify the driver name for each instance instead of inheriting the default from the driver: section.  There's an inheritance hierarchy down through the driver, platforms and provisioner stanzas.  Here's a simple example of the .kitchen.yml file that produced the kitchen list output above:

--- provisioner:   name: chef_solo platforms:   - name: ubuntu-13.10     driver:       name: vagrant       box: ubuntu-13.10       box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-13.10_chef-provisionerless.box   - name: centos-6.5     driver:       name: ec2       aws_access_key_id: <%= ENV['AWS_ACCESS_KEY'] %>       aws_secret_access_key: <%= ENV['AWS_SECRET_KEY'] %>       aws_ssh_key_id: <%= ENV['AWS_SSH_KEY_ID'] %>       ssh_key: "<%= ENV['HOME']%>/ec2/kitchen.pem"       security_groups_ids: ["sg-334a4258"]       region: us-east-1       availability_zone: us-east-1c       image_id: ami-8997afe0       username: root

suites:   - name: default     run_list:     attributes:

This is the beauty of the YAML format Test Kitchen uses - it's so flexible.  As you can so above, I don't bother having a driver: stanza, and I just supply the information directly in platforms: since there are only two.  I can spin up the Ubuntu 13.10 instance in vagrant with kitchen create default-ubuntu-1310 or I can spin up CentOS 6.5 in Amazon EC2 with kitchen create default-centos-65.  You can move common settings to the driver: stanza if you like.

By default Test Kitchen will create an instance for each entry listed in the suites: stanza.  If you want to restrict a suite to a particular platform, use the includes: statement.  For example if I change the suites: stanza of the above file:

suites:   - name: default   includes:     - centos-6.5   run_list:     - recipe[mycookbook::default]

Then the instance list will change accordingly:

Instance             Driver   Provisioner  Last Action default-centos-65    Ec2      ChefSolo     <Not Created>

To unsubscribe from this group and stop receiving emails from it, send an email to testing-with-chef+unsubscribe@googlegroups.com.

[Mischa Taylor]

There was a great discussion on translating ssh settings from a Vagrantfile to Test Kitchen here:

https://github.com/test-kitchen/kitchen-vagrant/issues/27

Test Kitchen does not support this feature directly (at present), but there are workarounds...

For me, since it's so easy to create boxes/AMIs with Packer, I just bake in the appropriate settings in the ~/.ssh/config

Host 127.0.0.1
  ForwardAgent yes

I believe the Chef Bento boxes have this in them, so SSH agent forwarding should just work, but personally I don't use those boxes in my work at Chef Software given that part of my job is writing custom Packer templates for things Bento doesn't cover, so I don't know exactly

Another workaround is to create and tell Test Kitchen to use your own customized Vagrant.erb template, you can use all the wacky Vagrantfile where there might not be a Test Kitchen equivalent.  This is really easy to, here's a link to the default Vagrant.erb template that you can tweak with extra settings.  I do this frequently for certain edge cases where I still need to rely on something in vagrant that Test Kitchen passes through (as Test Kitchen still uses Vagrant behind the scenes where appropriate).

On Monday, April 28, 2014 2:15:32 PM UTC-7, Arthur autohandle wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to testing-with-chef+unsubscribe@googlegroups.com.

[Mischa Taylor]

While you can do fancy stuff with erb templates to a "if clauses" to the .kitchen.yml, I'd recommend keeping it simple and just create one suite for the gui version and another suite for the non-gui version.  There isn't a limit on the number of suites:

suites:   - name: default     run_list:

- recipe[apt]       - recipe[sublime-text]       - recipe[sublime-text::apt-file]   - name: gui     run_list:       - recipe[apt]       - recipe[sublime-text]       - recipe[sublime-text::apt-file]       - recipe[sublime-text::install-ubuntu-desktop]

You can DRY this up some more by getting jiggly with the YAML (&, *, <<) constructs to define repeated sections as detailed here in this stack overflow explanation: http://stackoverflow.com/questions/6651275/what-do-the-mean-in-this-database-yml-file  (But probably overkill for this simple example, though I do like the link to the online YAML parser -  http://yaml-online-parser.appspot.com).  And expect to get a lot of WTFs from your colleagues if you pull this stunt:

suites:   - name: default     run_list:

- &common       - recipe[apt]       - recipe[sublime-text]       - recipe[sublime-text::apt-file]   - name: gui     run_list:       - *common       - recipe[sublime-text::install-ubuntu-desktop]

On Monday, April 28, 2014 2:15:32 PM UTC-7, Arthur autohandle wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to testing-with-chef+unsubscribe@googlegroups.com.

[Mischa Taylor]