vagrant provision with chef-solo fails with NFS and/or VMware Fusion as the mount breaks

[tmatilai]

The Install action with the chef-solo provisioner causes the local "berkshelf" directory (i.e. the cookbook_path component) to be deleted and re-created. In the released versions that is done by Berkshelf, and in master by ourselves. NFS and HGFS mounts don't like this and are left in a non-functional state, at least with an OS X host and Debianoid guests. Surprisingly vboxsf seems to be fine with that, though.

vagrant provision then fails either when validating the mount (with test -d) or while running chef-solo. vagrant reload --provision works as expected as it restarts the VM.

The simplest setup to repro this is to have a Berksfile:

site :opscode
cookbook 'ckbk'

and Vagrantfile:

Vagrant.configure('2') do |config|
  config.vm.box = 'precise32'
  config.vm.network :private_network, ip: '192.168.33.10'
  config.vm.provision :chef_solo do |chef|
    chef.nfs = true
    chef.add_recipe 'ckbk'
  end
end

I don't know when this broke with the Fusion provider, as it definitely worked after #24. NFS might have had problems all the time. Dunno.

I'm not sure how to fix this. I don't know if it is possible to fix the mounts in a cross-FS/OS way. The best would probably be to avoid removing the local directory but that requires changes in Berkshelf, too.

Poking also @mitchellh hoping he has some good easy solution. =)

PS: Thanks for all the hard (FOSS) work!

[alappe]

Yeah, I had this issue for several weeks now… sadly I can't provide more information, but I'm also hoping for a fix…

[beaugunderson]

Just bought the VMware provider today and was disappointed that I'm unable to use vagrant-berkshelf with it (even using vagrant reload --provision).

[reset]

@beaugunderson sadly I do not have a copy of the vmware provisioner. I'm pretty sure I have a copy of vmware fusion on my desk though.

If @mitchellh want's to hook me up with the provisioner I could try to dig into this one! ;)

[tmatilai]

@reset you can repro it also with Virtualbox using NFS. Just set chef.nfs = true for the chef-solo provisioner.

[reset]

pretty sure that these two issues are related: berkshelf/berkshelf#525

[wwestenbrink]

I use some rake taks to workaround this problem until its fixed
https://gist.github.com/wwestenbrink/6913828

[rbhitchcock]

Ran into this issue today as well. @wwestenbrink the link appears to point to a non-existent gist. Could you repaste?

[tmatilai]

Just a note that chef.nfs does nothing in Vagrant 1.4.* (a regression). Don't get confused if trying to reproduce with it.

Anyway, based on comments in berkshelf/berkshelf#525 it seems that Berkshelf unfortunately won't change it behavior, so vagrant-berkshelf should use a temp directory where it vendors the cookbooks, and then copies those into the synced directory.

[addisonj]

+1 on this, @tmatilai if you could expand on the details of your proposed fix, I could perhaps open up a PR

[wwestenbrink]

berks install -p tmp_folder
rsync -aW --delete tmp_folder/* cookbook_folder
vagrant provision

[tmatilai]

The badass ( 🐔 ) I am, I would maybe still first make a PR for Berkshelf:Berksfile#vendor to only require that the destination directory is empty (instead of non-existing), and modify it to install the cookbooks directly there without using tempdir.

If that gets rejected, then vagrant-berkshelf should get a safe tempdir path (but delete the dir), Berksfile#vendor into it, remove the previous content from the synced cookbook dir, move all the content under tempdir, and finally remove the (empty) tempdir. The code in vendor method can be used to get ideas how to do this.

rsync would be faster, but unfortunately it is not very portable (Windows, anyone?).

[reset]

@tmatilai it's fine for #vendor to just check the permissions on the target directory instead of it's existence

[parnurzeal]

Hi,
In the end, has it already been solved?
Because I am facing the same issue and doing "vagrant reload" then "vagrant provision " does not help me.
I need to do "vagrant reload --provision "

[ddaws]

My solution was to place

config.vm.provision "chef_solo" do |chef|
    chef.cookbooks_path = "./chef/cookbooks"
  end

where the directory

├── chef/
│   ├── Vagrantfile
│   ├── cookbooks
│   └── data_bags
├── Vagrantfile
├── Berksfile
└── metadata.rb

I then vendored my cookbooks using berks vendor chef/cookbooks. This was my work around, so I may still manage my cookbooks using berks, though this of course greatly under utilizes berkshelf, and it ability to centrally store cookbooks.

[jharley]

For what it's worth, here's a hacky patch to get vagrant provision working again with VMWare Fusion. Tested on Mavericks, with Vagrant 1.5, berkshelf 3.1, vagrant-berkshelf 2.0.1, and vagrant-vmware-fusion 2.4.0:

https://gist.github.com/jharley/5ac589354e41fadad0eb

[phillipsnick]

Besides the patch provided by @jharley has there been any improvements to resolve this?

Bit of a pain having to reload the machine every time you want to quickly test out a new cookbook/recipe you have just written.

[sethvargo]

@phillipsnick no resolution yet, but I'm working on a rewrite of Vagrant Berkshelf soon(tm)

[phillipsnick]

Cool, if you need a beta tester let me know :)

[sethvargo]

@phillipsnick #233

[sethvargo]

This is fixed now that 4.0.0 is released and we no longer delete the vendored Berkshelf directory.

[ddaws]

👍

[phillipsnick]

Since installing 4.0.0 I haven't had any issues with the vagrant provision command using NFS shares

Thanks

👍