-
Notifications
You must be signed in to change notification settings - Fork 15
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.
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
Enable parallel provisioning #16
Comments
Turning it on is pretty straightforward according to the docs, whether softlayer_api (/xmlrpc), and what we have ontop of softlayer_api are thread safe is another. If each box is creating its own SL API service instances then I dont think we have anything to worry about, but im not sure if they are or not. @underscorephil : Any thoughts on softlayer_api thread safety? |
@irifed: To enable until its officially enabled, edit Change: to Throws a few errors but otherwise works:
[Edit] I had a modified Vagrant log verbosity, when i retried with a normal log verbosity I got no errors so it looks ok. |
Howdy! I just spoke with @SLsthompson. While there is nothing in the lib to ensure thread safety, he nor I see anything that would prevent the use of the parallel feature. |
@ju2wheels : thanks for suggestion!
Looks like the error is caused by some timeout while waiting for provisioning. I've found a couple of timeout values in the plugin source, but they are set to 20mins. I was getting these errors after ~4mins of waiting. Same Vagrantfile works without errors if parallel is not enabled. Any ideas which timeout should be increased? Thanks! |
The only vagrant specific timeouts im aware of are the Based on the above though, I dont think vagrant/vagrant-softlayer is the issue since if we raise those values high enough we will then be bound by the default HTTP timeouts associated with I tried to issue SoftLayer::Service#xmlrpc_client.timeout= call but its private so I dont think we can increase the timeout currently. SoftLayer::Service The default timeout is 30s according to docs. [Edit] Was looking at the wrong version but both seem to have the same problem: 1.x branch is based on Net::HTTPS (w/ 60s default read_timeout) and the 2.x on XMLRPC (w/30s default timeout as far as I can tell). |
Adding the timeout is a source compatible change. Let me see if I can get that in there and put out a dot release. |
Hi guys, just wanted to add interest to this thread. Ill be trying the tip for enabling parallel support tonight and would be happy to test any release with official support. Cheers |
@marianormuro : beta testing latest patches without manually changing:
This will include all changes in #15 |
@irifed : thanks to @SLsthompson for some quick fixes on Please try the following:
Warning: Installing softlayer_api may trigger vagrant to install nokogiri (or at least it did for me, even though I dont think its needed) and the latest version will require that you have Xcode and gcc equivalent compiler if using a Mac I think (theres a bunch of open tickets upstream about this). Set |
That seems weird. softlayer_api by itself doesn't depend on nokogiri an none of the gems we depend on do either. It it something in the vagrant environment that asks you to install nokogiri when the softlayer_api gem is used? |
Based on what I have read upstream its something to do with the way Vagrant uses bundler. |
OK. Just wanted to make sure that I wasn't doing something silly... wouldn't have been the first time. |
@ju2wheels I've just pushed a development branch, please use that for any future pull request. Thanks 😉 |
Parallel execution capability has been added with the release 0.3.3 |
In 0.3.3, with multiple instance config blocks in a single file and without specifying the --parallel flag, one can get errors in one or more host initializations if the instances contend for common files such as the cookbook rb files. For example, I had 3 out of 4 instances successfully initialize but the 4th failed when it complained that one of the cookbook rb files did not exist. The file did exist, the first 3 found it, and it was present at the end of the run. There may be a file access timeout that the 4th accessor experienced that the first 3 did not. I'll try with --parallel to see if that makes a difference. |
@lonniev can you provide a stripped down example and output of the error? If you arent using the parallel flag then they are going sequentially and wouldnt make sense for their to be contention for file access on the vagrant host unless one of the instances is depending on a file created by a previous one or a file removed by a previous one... Please open as a separate issue. |
I’ll commit the current Vagrantfile and then open a separate issue for the file contention issue. —Lonnie VanZandt 303-900-3048 On Mon, Oct 27, 2014 at 6:38 PM, Julio Lajara notifications@github.com
|
Hi @emyl , I noticed that currently it is not possible to create instances in parallel with
--parallel
flag. Are there any plans to enable this?I would be happy to contribute, but I am new to Vagrant plugins development. Do you think this would take a lot of effort? Where to look at first?
Thanks!
The text was updated successfully, but these errors were encountered: