2

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)
stoebelj
  • 1,536
  • 2
  • 14
  • 31

2 Answers2

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.

coderanger
  • 52,400
  • 4
  • 52
  • 75
  • Thanks! This answers the original question perfectly, but now I have a new issue. See above. – stoebelj Feb 13 '17 at 10:56
  • Yes but I get a warning, don't know if its related: `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.` – stoebelj Feb 13 '17 at 18:47
  • That's fine, known bug in berks but the issue is just a warning. It sounds like `vagrant-berkshelf` isn't finding the correct executable. It uses `Which.which('berks')` and isn't otherwise configurable. Check your `$PATH`. – coderanger Feb 13 '17 at 18:57
  • Here's my path `/Library/Frameworks/Python.framework/Versions/3.4/bin:/Users/stoebelj/.rbenv/shims:/usr/local/bin:/opt/chefdk/bin:/usr/local/bin/chef:/usr/local/share/python:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/stoebelj/.npm-global/bin/` – stoebelj Feb 13 '17 at 19:11
  • Oh hey, you still have the berks with the busted Hashie warnings, that might interfere with the version parser. Try `chef gem install berkshelf`? – coderanger Feb 14 '17 at 22:43
  • Thanks for the input! That unfortunately doesn't change things. – stoebelj Feb 15 '17 at 19:04
  • Does `berks --version` show just the version output now? – coderanger Feb 15 '17 at 19:41
  • You mean you still see the hashie warnings? If so, the upgrade didn't work and vagrant-berks still can't parse the version number. – coderanger Feb 16 '17 at 18:39
1

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"

MarkII
  • 872
  • 1
  • 9
  • 26
  • Thanks, this worked! Both of the answers given here, combined solved my problem. There isn't a way to accept both, so I am accepting the first answer as it solved the original problem. Yours solves the secondary problem. – stoebelj Feb 16 '17 at 21:01