Fwiw, last night I upgraded to Test-kitchen alpha2, Berkshelf 1.4 rc1
and vagrant 1.1.5.dev and my test kitchen (kitchen test) and Berkshelf
test (vagrant up) both worked great. Any issues I had or was able to
reproduce before can be chalked up to a bunch of meddling in my gem code.
I think it’s worth mentioning that you shouldn’t delete the line that
says ‘metadata’ in your Berksfile.
saschas-MacBook-Air:chef-ci sascha$ cat Gemfile
gem ‘berkshelf’, '1.4.0.rc1’
gem ‘test-kitchen’, ‘1.0.0.alpha.2’, :group => :integration
gem ‘kitchen-vagrant’, ‘0.7.4’, :group => :integration
gem ‘vagrant’, ‘1.1.5.dev’
Sascha Bates mailto:firstname.lastname@example.org
March 28, 2013 2:57 PM
I just ran through a Berksfile test and am seeing the same thing. I
changed one thing in the Vagrant file and that was to use a local
centos6.3 box I already had instead of downloading another box.
Otherwise it was plain vanilla Berkshelf with only the local cookbook
I was testing, no external deps.
I added into the Vagrantfile: chef.cookbooks_path =
"/Users/sascha/pathto/cookbooks" to the provisioning section and that
I’ve had the same problem with test-kitchen’s vagrant plugin as well
so I’m wondering if there’s something different with new Vagrant and
how it’s doing cookbook path discovery?
Andrew Hollingsworth mailto:email@example.com
March 28, 2013 1:06 PM
I had a similar problem and it turned out to be the way my client was
abstracting their box configuration similar to the following :
Vagrant.configure(“2”) do |config|
config.vm.synced_folder “srv”, “/srv”, “/srv”
config.vm.define :mybox do |mybox_config|
mybox_config.vm.box = “mybox.dev”
<snip but everything defined around mybox_config (instead of just config)>
Instead of just using a more standard setup like :
Vagrant.configure(“2”) do |config|
config.vm.synced_folder “/srv”, “/srv”, :nfs => true
config.vm.box = “mybox.dev”
config.vm.network :private_network, ip: "192.168.12.23"
config.vm.network :forwarded_port, guest: 22, host: 2322
<snip - all other definitions etc.>
Having the extra abstraction for mybox_config prevented berkshelf from
working correctly for some reason. Changing to the standard way fixed
Thought it was worth mentioning in case your Vagrantfile is similarly
Mark Pimentel mailto:firstname.lastname@example.org
March 28, 2013 8:58 AM
I still cannot get vagrant provision to work with chef-solo. I
followed your upgrade steps below, and then ran …
On the up command it brings up the vagrant box as expected.
On the provision step, it invokes the berkshelf plugin to download all
the cookbooks as defined the Berksfile to some isolated directory for
this vagrant box. But then when it runs the actual chef-solo run, it
cannot find any cookbooks. Am I missing something here? Shouldn’t
the berkshelf plugin somehow be injecting the path or creating a
shared folder to the isolated download directory so chef-solo in the
VM can find its cookbooks?
On 2013-03-26 12:08 PM, Andrew Gross wrote:
Andrew Gross mailto:email@example.com
March 26, 2013 11:08 AM
I managed to get the upgrade working, was a little bit of a struggle.
- Install new Vagrant DMG (on mac)
- Uninstall Vagrant Gem (from system, rvm, bundler whatever)
- Install Berkshelf Vagrant Plugin (
vagrant plugin install berkshelf-vagrant)
- Upgrade Berkshelf Gem to 1.3.*
- Rerun Berks install
- Remove any ‘require Berkshelf’ sections from my Vagrantfile
- Remove references to ‘config.berkshelf.berksfile_path’ from Vagrantfile
vagrant upseems to not do a
vagrant provisionautomatically, so
now I have to chain the commands.
.vagrantfile is now actually a folder, so make sure to use rm
-rf to clean up afterwards.
Granted my Vagrantfiles are very simple, so there may be more
Brian Akins mailto:firstname.lastname@example.org
March 26, 2013 9:09 AM
I had so many issues with upgrading Vagrant that I decided to go back
to 1.0 for now. I needed Berkshelf integration. I could not get the
"new" berkshelf-vagrant to work with vagrant 1.0, but that may be just
So, here’s my hack that others may find helpful - if only as comedic