This repository has been archived by the owner on Dec 26, 2017. It is now read-only.
Provisioning crashes with 2.0.1 and vagrant 1.5.4 #188
Labels
Comments
|
@mitchellh is this what I think it is? Is i18n monkey patching |
|
@sethvargo Hash#fetch always raises a KeyError when a key doesn't exist. That is the difference between |
|
Awkard... |
|
Soooo. Ridley calls |
|
MONKEY PATCHING BITES HARD |
|
Ubuntu 12.04, Vagrant 1.5.2 |
|
@danylevskyi you need to update your version of vagrant-berkshelf |
|
Any updates? :) I am getting the same error with the same versions as the issue creator. |
|
@he9lin this is a confirmed bug |
|
I am getting the following exception only when using chef_client provisioner, if I use chef_solo provisioner it works fine. It seems to be related to the same issue. /Applications/Vagrant/embedded/gems/gems/i18n-0.6.9/lib/i18n/core_ext/hash.rb:4:in `fetch': key not found: :retries (KeyError) Versions |
|
Are comments being deleted?? |
|
Ask GitHub? Not sure. |
|
My question earlier if anybody knew how to patch this out themselves was deleted.. |
|
Re-post? |
|
Do we have any thoughts on where to start with this one? |
|
@ivey this is old berkshelf. I'm not sure it's going to make the priorities board, but I think we would welcome a community fix. |
|
I am confused what you mean by old berkshelf? In my environment, this is running against the latest vagrant, berks 3.0, Or do you mean an old way of doing things? If thats the case, then I On Fri, May 16, 2014 at 10:53 AM, Seth Vargo [email protected]:
|
|
@addisonj this issue is for Berkshelf 2:
|
|
vagrant-berkshelf 2.0.1, but berkshelf 3 underneath that. Look at the stack trace, it goes through berkshelf 3: |
|
@sethvargo yeah this is the latest stuff. It's an easy fix - we just pass the object to the module function to avoid the monkey patching bullshit. |
|
Correct, this is occurring in berks 3.1.2 as well. |
|
@sethvargo @ivey these two issues will solve the problem: berkshelf/buff-extensions#4 berkshelf/buff-extensions#5 |
|
|
FWIW, I am getting this in Vagrant 1.6 w/ VagrantBerkshelf 2.0.1 Chef soloChef Client |
|
@johntdyer that's the same error. ALL - okay. It's an issue. Please stop crowding the conversation with "me too" and "+1". Debugging output (that is different than those already posted) is incredibly valuable (like what @johntdyer provided). We are confirming this is an issue. If you would like to track progress, please click the "Subscribe" button. |
|
If you are interested in tracking progress at a lower level, this is the PR which will fix the problem: berkshelf/buff-extensions#4 |
|
Possible solution for some folks... Try removing the vagrant-omnibus plugin and any config.omnibus.chef_version lines from your Vagrantfile. For a long while we were chasing down berks-api and berkshelf issues and it turned out to be neither. TMI |
|
Similar stacktrace although slightly different source, from windows vagrant up command. |
|
I am having the exact problem and try to patch it but I am confused. One of the comment here said to refer to RiotGames/buff-extensions/hash.rb , do I use that patch to appy to the hash.rb in i18n-0.6.9 gem? |
|
Any progress on this? I hate to be that guy but looking at the underlying issues mentioned by @reset, the code is there (berkshelf/buff-extensions#4) but simply hasn't been merged yet? Would really looove to be able to use this workflow with newest vagrant :) |
|
Hi all, |
|
We just released vagrant-berkshelf v3.0.0.rc1 which should fix this issue. Can people please help us test? |
|
@addisonj like @sethvargo mentioned, this is fixed in the release candidate that I published yesterday. I haven't gotten anyone to test it on Windows yet which is why it's still just a release candidate. This is fixed in master so closing this ticket. |
|
I just gave 3.0.0.rc1 a try and it totally broke my vagrant. Noodles-2: barrowkwan$ vagrant plugin list Noodles-2: barrowkwan$ vagrant up The problem seem to be the function parse the entire ~/.berkshelf/config.json instead of the path to the config.json. So I delete ~/.berkshelf/config.json and run it again. Noodles-2: barrowkwan$ vagrant up eval'\n\tfrom /Users/barrowkwan/.rvm/gems/ruby-1.9.3-p547@chef/bin/ruby_executable_hooks:15:in '\n">
On Thursday, July 24, 2014 1:04 PM, Jamie Winsor [email protected] wrote: Closed #188. |
|
I also had that same problem, but didn't have time to dig deeper. On Thu, Jul 24, 2014 at 7:23 PM, Barrow Kwan [email protected]
|
|
@barrowkwan @addisonj it was an issue reading a berkshelf configuration if it were present. Fixed and released in |
|
I also had a same issue. Uninstall vagrant omnibus resolved the issue. It's working fine. |
|
I can confirm that removing and reinstalling vagrant-omnibus plugin solves the issue for when using vagrant-berkshelf 2.0.1. However, using vagrant-berkshelf 3.0.0 gave me this error instead #213 |
|
Was still getting this issue on berks v3.1.3, but managed to get around it by switching my gemsets to global: |
|
I'm also getting the 'RuntimeError: Couldn't determine Berks version: #<Buff::...' From the stack trace, it looks like vagrant is looking for berkshelf gem, but vagrant is using its gems from its installed-by-the-msi embedded ruby, and berkshelf gem is located in the installed-by-the-chefdk-msi ruby. Looking to see if this is a separate already-reported issue, but if I extract the metadata from the plugins' .gem file and crack it with a text editor, it doesn't explicitly depend on berkshelf ruby gem. Probably there's a right place to add that? (edit: assuming that then, installing the plugin with vagrant would download and cache a version of the berkshelf gem for itself - if it has to match the one in my chefdk, don't know the mechanics of how it would test/detect that). |
|
No, the gem is no longer a dependency. The plugin will now shell out to the ChefDK installed berks command. Typically any issues with loading the gem were because the users path is not setup with the ChefDK directory infront of their rvm, rbenv, or vagrant directories. It's crucial that any rbenv or rvm init happens before you add ChefDK to your path. Jamie Winsor
|
|
Ok, thanks for explanation of the importance of PATH. I've forced chefdk bin dirs to start of PATH, and I'm still getting this error on windows. Poking at it. |
|
Thanks Jamie. |
|
Thanks, indeed. Moving the ChefDK towards the tail end of my path took care On Fri, Aug 8, 2014 at 1:59 PM, Sia Gholami [email protected]
|
|
PATH error here too; a stale chef-client path was hosing me. Thanks for the help. Part of me thinks, maybe when this assert bubbles up, we could print a friendlier 'check your PATH' message. But the other part of me thinks, the assertion is fairly unique and says what's wrong (without mentioning PATH). |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When provisioning a new VM or reprovisioning an existing one, vagrant crashes with one of the two following stack traces: (edited slightly to hide private info)
This occurs most of the time:
but occasionally get this instead:
Version info:
The text was updated successfully, but these errors were encountered: