config.rb expand_path: no implicit conversion of Proc into String

[rhardouin]

Hi,

I've just run OpenStack Monasca which uses vagrant-berkshelf-2.0.1 and got the following error:

/home/romain/.vagrant.d/gems/gems/vagrant-berkshelf-2.0.1/lib/berkshelf/vagrant/config.rb:58:in 'expand_path': no implicit conversion of Proc into String (TypeError)
from /home/romain/.vagrant.d/gems/gems/vagrant-berkshelf-2.0.1/lib/berkshelf/vagrant/config.rb:58:in 'validate'
from /usr/lib/ruby/vendor_ruby/vagrant/config/v2/root.rb:68:in 'block in validate'
from /usr/lib/ruby/vendor_ruby/vagrant/config/v2/root.rb:64:in 'each'
from /usr/lib/ruby/vendor_ruby/vagrant/config/v2/root.rb:64:in 'validate'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builtin/config_validate.rb:15:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /home/romain/.vagrant.d/gems/gems/vagrant-berkshelf-2.0.1/lib/berkshelf/vagrant/action/configure_chef.rb:22:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /home/romain/.vagrant.d/gems/gems/vagrant-berkshelf-2.0.1/lib/berkshelf/vagrant/action/load_shelf.rb:27:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /home/romain/.vagrant.d/gems/gems/vagrant-berkshelf-2.0.1/lib/berkshelf/vagrant/action/set_ui.rb:11:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builtin/env_set.rb:19:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:95:in 'block in finalize_action'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builtin/handle_box.rb:56:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:95:in 'block in finalize_action'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in 'block in run'
from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in 'busy'
from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in 'run'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builtin/call.rb:53:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in 'block in run'
from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in 'busy'
from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in 'run'
from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:196:in 'action_raw'
from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:173:in 'block in action'
from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:440:in 'lock'
from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:161:in 'call'
from /usr/lib/ruby/vendor_ruby/vagrant/machine.rb:161:in 'action'
from /usr/lib/ruby/vendor_ruby/vagrant/batch_action.rb:82:in 'block (2 levels) in run'

config.rb:58 is:

 @client_key = File.expand_path(@client_key, machine.env.root_path.to_s)

So I made a dirty hack like this and it works fine:

if @client_key .kind_of? Proc
    @client_key = @client_key.call()
end
@client_key = File.expand_path(@client_key, machine.env.root_path.to_s)

I don't know at all vagrant-berkshelf, a neater fix is surely needed.

Best,
Romain

[sethvargo]

Same error as #227, but this seems like a real bug.

[colby]

Can confirm, just bit by this too. On the same berkshelf version on Vagrant 1.6.3

[mjsuhonos]

++ just got this as well. @rhardouin's fix worked for me. I simplified the syntax a bit:

@client_key = @client_key.call if @client_key.kind_of? Proc

[ruebot]

Ran into the same thing today. @rhardouin's fix worked for me as well. 👍

[dmcnelis]

Confirming as the others, the @rhardouin fix works.

[sethvargo]

This is a ridley issue and is being tracked on Ridley: berkshelf/ridley#285

[ehaselwanter]

@sethvargo so this is closed here and there. but no actual code change? just asking 'cause I'm hit by something similar (maybe vagrant-chef-zero related)

Uploading cookbooks to 'http://192.168.1.16:4002'
Berkshelf::BerksError: Berks command Failed: /opt/chefdk/bin/berks upload  --config=/var/folders/q8/20s7jvws4n7f0ph12r7j9vf00000gn/T/berks-config20141125-16474-gbldys --berksfile=Berksfile  , reason: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/ridley-4.1.0/lib/ridley/client.rb:142:in `expand_path': no implicit conversion of Proc into String (TypeError)
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/ridley-4.1.0/lib/ridley/client.rb:142:in `initialize'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/celluloid

but fixing this just brings to more yak shaving

141       unless verify_client_key(@options[:client_key])
   142         @options[:client_key] = @options[:client_key].call if @options[:client_key].kind_of? Proc
   143         @options[:client_key] = File.expand_path(@options[:client_key])

Uploading cookbooks to 'http://192.168.1.16:4002'
Berkshelf::BerksError: Berks command Failed: /opt/chefdk/bin/berks upload  --config=/var/folders/q8/20s7jvws4n7f0ph12r7j9vf00000gn/T/berks-config20141125-16698-10alnqd --berksfile=Berksfile  , reason: /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/ridley-4.1.0/lib/ridley/client.rb:144:in `read': Permission denied @ rb_sysopen - /etc/chef/client.pem (Errno::EACCES)
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/ridley-4.1.0/lib/ridley/client.rb:144:in `initialize'
    from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/celluloid-0.16.0/li

but I've read that there are some changes coming in 1.7 ?

what's your advice on using berkshelf with zero at the moment?

[sethvargo]

@rhardouin it's not closed on Ridley. This is a Ridley issue, not a Vagrant-Berkshelf/Berkshelf issue.

[martin-fuller]

I hit this issue earlier today, and though I have not fixed anything really, I did find a workaround.
I set up a ~/.chef/knife.rb in the process of setting up my hosted chef to get around using zero (which i was going to use for a nagios cookbook), and now it no longer hits the block of code that causes the failure (for me anyway).

Specifically the section for chef-repo: https://docs.getchef.com/install_dk.html

[cbreden]

@ehaselwanter Were you able to arrive at a working vagrant-berkshelf and vagrant-chef-zero combination? I'm a bit baffled due to thinking this was a common setup. From the vagrant-chef-zero readme:

[Cookbooks] are uploaded via the Ridley gem. It is the same backend that Berkshelf uses, though I am sure my usage is not as complete. It expects a path to a cookbooks/ directory, or an array of paths to individual cookbooks. If you omit this field, you can have Berkshelf upload cookbooks as usual (It will find the Chef-Zero URL automatically).

I don't see where it sends the berks command (and ridley) the IP address it says it's uploading to.

[cristianmtr]

Caught the same bug. @rhardouin fix worked. Why hasn't this been fixed?