Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Test Kitchen 1.2.0 breaks Berkshelf 2.0 on (OS X) #357

Closed
tmatilai opened this issue Feb 12, 2014 · 4 comments · Fixed by #358
Closed

Test Kitchen 1.2.0 breaks Berkshelf 2.0 on (OS X) #357

tmatilai opened this issue Feb 12, 2014 · 4 comments · Fixed by #358
Assignees
@fnichol
Labels
Bug

Comments

@tmatilai
Copy link

The latest release seems to cause problems with Berkshelf 2.0. Berkshelf from master works. Git bisecting blames this concurrency commit in PR #293.

OS X 10.8.5
Ruby MRI 2.0.0-p353
berkshelf 2.0.14
test-kitchen 1.2.0
kitchen-vagrant 0.14.0
Vagrant 1.4.3

The same issue has been seen with 1.9.3 too.

$ bundle exec kitchen converge -l debug
-----> Starting Kitchen (v1.2.0)
D      [kitchen::driver::vagrant command] BEGIN (vagrant --version)
D      [kitchen::driver::vagrant command] END (0m0.48s)
-----> Converging <default-debian-7>...
D      Creating Vagrantfile for <default-debian-7> (/tmp/foo/.kitchen/kitchen-vagrant/default-debian-7/Vagrantfile)
D      ------------
D      Vagrant.configure("2") do |c|
D        c.vm.box = "debian-7"
D        c.vm.hostname = "default-debian-7.vagrantup.com"
D        c.vm.synced_folder ".", "/vagrant", disabled: true
D        c.vm.provider :vmware_fusion do |p|
D          p.vmx["memsize"] = "256"
D        end
D      end
D      ------------
       Preparing files for transfer
D      Creating local sandbox in /var/folders/gv/3rc7k73s6jvctsc87qvy6flc0000gn/T/default-debian-7-sandbox-20140212-38043-kb2f39
       Resolving cookbook dependencies with Berkshelf...
D      Using Berksfile from /tmp/foo/Berksfile
[2]    38043 trace trap  bundle exec kitchen converge -l debug
@fnichol fnichol self-assigned this Feb 12, 2014
@fnichol
Copy link
Contributor

fnichol commented Feb 12, 2014

Just for completeness, do you have a Berksfile or metadata.rb available to see what kind of cookbooks are coming in? Thanks!

@tmatilai
Copy link
Author

@fnichol ah, good point. I was using cookbooks from private Chef server, but I can reproduce the problem also with totally empty Berksfile.

@fnichol
Copy link
Contributor

fnichol commented Feb 12, 2014

Even better, simple case :)

@fnichol fnichol added the Bug label Feb 12, 2014
@fnichol
Copy link
Contributor

fnichol commented Feb 12, 2014

Confirmed, this appears to be an issue with MRI Ruby (possibly only on Mac) when trying to load dynamic libraries (native code) in a thread that is not the main thread. This article was the tip-off.

I'm looking at a way for Berkshelf/Librarian-Chef libs to be loaded at provisioner object creation time rather than late loading when in a thread. the downside is that kitchen list commands will be slower and kitchen diagnose could be harder to make work no matter what.

fnichol added a commit that referenced this issue Feb 12, 2014
@fnichol
Load needed (dynamic) dependencies for provisioners at creation time.
954a3ff 
The need for this change was initated with #293 which runs every
instance action in a thread of execution, even in serial mode. The issue
is that on the Mac platform MRI Ruby 1.9 and 2.0 (not confirmed for
2.1), dynamic (i.e. native) code needs to be loaded in the main thread
otherwise causing a "Trace/BPT trap: 5" crash.

References:

* http://stackoverflow.com/questions/9933969/matlab-ruby-gem-doesnt-work-when-called-from-thread#answer-12319780
* https://bugs.launchpad.net/sbcl/+bug/1014409

For Berkshelf 2.0.x at least, there are multiple transitive dependencies
that *could* load native code, meaning that `require 'berkshelf'` could
very well lead to a VM crash if performed in a thread other than main.

This commit pushes library loading code ahead to Provisioner creation
time. In other words, by the time you have a Provisioner object
reference either Berkshelf, Librarian-Chef, or nothing has been required
(assuming a Chef provisioner).

A drawback to this approach is that these dynamic dependencies will be
eagerly loaded when Test Kitchen is booting for trivial CLI commands
such as `kitchen list` and `kitchen diagnose`. Further work is needed to
ensure that `kitchen diagnose` remains viable even in the face of a
failure to load these dependencies.

Finally, the loaded version of Berkshelf or Librarian-Chef will be
displayed to the user on INFO for converge action and DEBUG on code
loading for troubleshooting.

Closes #357

/cc @reset, @ivey, @sethvargo
@fnichol fnichol mentioned this issue Feb 12, 2014
Merged
fnichol added a commit that referenced this issue Feb 12, 2014
@fnichol
Record failures to build instances when running kitchen diagnose.
c8e6f12 
In resolving #357 some code loading logic needed to be moved early in
an object's life meaning that an Instance (or a collaborator object)
could crash before `#diagnose` was callable.

A design goal for `kitchen diagnose` is that it not crash itself and to
provide some minimum useful information in a failure scenario.

This commit will return an error hash in the :instances and :loader keys
if an exception was raised.
@test-kitchen test-kitchen locked and limited conversation to collaborators Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@fnichol fnichol

Labels
Bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Load needed (dynamic) dependencies for provisioners at creation time. test-kitchen/test-kitchen
2 participants
@tmatilai @fnichol