Provisioning Vagrant box with chef-solo and vagrant - vagrant

Question

I want to spin up a Vagrant box and provision a LAMP stack using chef-solo and berkshelf. Here's the steps I take:
berks cookbook my_project
Then in Berksfile:
site :opscode
cookbook 'wordpress', '~> 3.0.0'
cookbook 'apache2', '~> 3.2.2'
cookbook 'mysql', '~> 8.2.0'
cookbook 'php', '~> 2.2.0'
Then berks vendor cookbooks
The Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = '2'
Vagrant.require_version '>= 1.5.0'
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.hostname = 'unify-config-berkshelf'
if Vagrant.has_plugin?("vagrant-omnibus")
config.omnibus.chef_version = 'latest'
end
config.vm.box = 'bento/ubuntu-14.04'
config.vm.network :private_network, type: 'dhcp'
config.vm.provision :chef_solo do |chef|
chef.json = {
mysql: {
server_root_password: 'rootpass',
server_debian_password: 'debpass',
server_repl_password: 'replpass'
}
}
chef.run_list = [
"recipe[apache2]",
"recipe[apache2::mod_php5]",
"recipe[mysql::client]",
"recipe[mysql::server]",
"recipe[php]",
"recipe[php::module_mysql]"
]
end
end
Then I try to bring the box up with vagrant up. This is the error I get.
The following berks command failed to execute:
/Users/stoebelj/.rbenv/shims/berks --version --format json
The stdout and stderr are shown below:
stdout:
stderr: Ignoring ffi-1.9.14 because its extensions are not built. Try: gem pristine ffi --version 1.9.14
Ignoring nokogiri-1.6.7.1 because its extensions are not built. Try: gem pristine nokogiri --version 1.6.7.1
Ignoring unf_ext-0.0.7.2 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.7.2
Ignoring wdm-0.1.1 because its extensions are not built. Try: gem pristine wdm --version 0.1.1
/Users/stoebelj/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/dependency.rb:319:in `to_specs': Could not find 'berkshelf' (>= 0.a) among 47 total gem(s) (Gem::LoadError)
Checked in 'GEM_PATH=/opt/vagrant/embedded/gems', execute `gem env` for more information
from /Users/stoebelj/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/dependency.rb:328:in `to_spec'
from /Users/stoebelj/.rbenv/versions/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:65:in `gem'
from /Users/stoebelj/.rbenv/versions/2.3.1/bin/berks:22:in `<main>'
It appears that you are not using the ChefDK. Please note that Vagrant Berkshelf
works best when used with the ChefDK, and other installation methods are not
officially supported.
Please download and install the latest version of the ChefDK from:
https://downloads.chef.io/chef-dk
and follow the installation instructions. Do not forget to add the ChefDK to
your PATH.
I installed ChefDK from the URL given and /usr/local/bin/chef is in my PATH
What am I misunderstanding?
Update
A question below suggested I remove berkshelf from my rbenv, which did indeed get rid of the below error. Now I have a different error:
The Berkshelf version at "/usr/local/bin/berks" is invalid.
Vagrant Berkshelf requires >= 4.0, but the current version is .
Please download and install the latest version of the ChefDK from:
https://downloads.chef.io/chef-dk
and follow the installation instructions. Do not forget to add the ChefDK to
your PATH.
For context, I checked this which suggested I update my plugin. This did not work. I also tried removing the plugin and installing version 4.1 which also did not work.
And for context:
$ vagrant plugin list
vagrant-berkshelf (5.1.1)
vagrant-omnibus (1.5.0)
vagrant-share (1.1.6, system)
$ which berks
/usr/local/bin/berks
berks seems to work fine on its own but produces a warning I don't understand:
$ berks
W, [2017-02-13T13:46:00.590751 #3199] WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-02-13T13:46:00.591227 #3199] WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-02-13T13:46:00.591452 #3199] WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-02-13T13:46:00.591672 #3199] WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-02-13T13:46:00.629581 #3199] WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-02-13T13:46:00.629737 #3199] WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
Resolving cookbook dependencies...
Fetching 'unify_config' from source at .
Using apache2 (3.2.2)
Using build-essential (7.0.3)
Using compat_resource (12.16.3)
Using iis (5.0.5)
Using mingw (1.2.5)
Using mysql (8.2.0)
Using ohai (4.2.3)
Using php (2.2.0)
Using seven_zip (2.0.2)
Using unify_config (0.1.0) from source at .
Using windows (2.1.1)
Using xml (3.1.1)
Using yum-epel (2.1.1)

Answer 1

As shown in the command it is trying to run, the issue isn't the chef executable, it's berks. Remove the copy of that you installed via gems and makes sure the copy from ChefDK is working.

Answer 2

Ran into this issue couple days ago as well. Rolling back the version of ChefDK helped for me:
ChefDK 1.1.16
Coworker of mine was the one the dug up the reasoning, stating:
"vagrant uses berks -version --format json or something of the like to get the version of berks but running that command leads to some warning logs output by some dependency berks uses
which is why the version is blank"