Error occurred: no implicit conversion of Proc into String

[oguzy]

I am trying to up a test this: https://github.com/stackforge/monasca-vagrant

Using Ubuntu 14.04, Vagrant 1.6.5 and Virtualbox 4.3.10

vagrant up gives the below error:

[@sethvargo edit], moved stacktrace to gist: https://gist.github.com/sethvargo/8892ef246da6f45785ae

[leeacto]

Same issue.

Using Vagrant 1.6.5, Virtualbox 4.3.18, and OSX 10.10

[sethvargo]

@leeacto it would be very useful to have a Vagrantfile and some reproduction steps 😄

[leeacto]

Here's a link to the error output
https://gist.github.com/leeacto/3795eb35a15626c6813d

[shanesveller]

@sethvargo I've been helping @leeacto try to troubleshoot this error since Friday - none of our own repos with Vagrantfiles are public, but we could reproduce the problem with the same repo as @oguzy was using above, so the gist Nick posted is just the output of vagrant up --debug from a clone of https://github.com/stackforge/monasca-vagrant.

[sethvargo]

@oguzy @leeacto @shanesveller It appears from the stacktrace that you are using a very old version of Vagrant Berkshelf. The latest version is in the 3.x series and this is using the 2.x series...

[shanesveller]

@sethvargo We are currently not ready to treat chef-dk as a requirement for downstream devs consuming our Chef repo by way of Vagrant, because right now, even the folks who work in our Chef repo daily aren't using chef-dk yet.

I can understand not wanting to support old versions of this plugin. If the requirement on chef-dk could be loosened to support any local Berkshelf binary as mentioned in #223, I'd be happy to move us to vagrant-berkshelf 3.x. Until then, it sounds like we're kind of stuck.

[sethvargo]

@shanesveller unfortunately we no longer support Berkshelf or Vagrant Berkshelf 2.x because it's nearly impossible to manage so many Ruby environments 😦.

[shanesveller]

Understandable. Just to clarify: we do actually use Berkshelf 3.x just about everywhere, mostly via Bundler, so it was just the Vagrant plugin that we pinned to an older release.

[reset]

What's the hesitancy to ask your devs to install ChefDK? We put it together to make lives easier for devs. It's more work for them to install a sane Ruby version and then all of the gems.

[shanesveller]

@reset We are predominantly a Ruby shop, so most of our developers already have sane Ruby environments via rvm/rbenv, and are comfortable installing gems. We essentially want them to be able to clone a repo and run vagrant up and have a Chef-deployed copy of their apps ready in a few minutes, so Chef-DK becomes an additional, admittedly minor, hurdle to that workflow. Philosophically, it's a bit like how Rails developers will gripe about needing to install Node.js to power the asset pipeline.

[reset]

@shanesveller disk space is cheap, man. Make an install via curl script that downloads the necessary stuff and bootstraps their machines. It's even easier then asking somebody to clone a repo.

I'm going to close this issue out since it's from an old version of Berkshelf

[elskwid]

I realize this issue is closed but I ran into the same problem and have a little workaround that you can drop in your Vagrantfile to get you operational until you move to ChefDK or find another solution.

The actual source of this issue arises from a change to ridley where formerly String values are now returning Procs.

It looks like two of these default values are being used in v2.0.1 of vagrant-berkshelf. A quick test shows that these can be forced to evaluate by setting them to the result of the called Proc.

Here's what I used to do just that:

  if Berkshelf::Vagrant::VERSION == "2.0.1" && config.berkshelf.enabled
    %w[node_name client_key].each do |attribute|
      default = config.berkshelf.send(attribute)
      next unless default.respond_to?(:call)

      config.berkshelf.send("#{attribute}=", default.call)
    end
  end

@shanesveller, that gets you Strings where you expect them. Obviously, if you need to force evaluate more attributes you could just add them to the list.

I've dug around in buff-config and varia_model and I can't see anywhere that takes into account that an attribute may have a Proc but the caller may want the return of the called Proc. Further digging in newer versions of vargant-berkshelf didn't shed any light on it either.

As I was writing this I did another search of the issues and saw that #228 is the same.

Let me know if you need anything more from me or if I can help in any way. I hope this helps.

[paulmorriss]

@elskwid That worked for me. I'm new to this stuff, but I dropped in into a Vagrant file on someone else's project and it worked.

[muelli]

I've also run into this issue. The snippet a few comments up works. I have to make the if condition a tautology, though.