Yep, test kitchen / kitchen-vagrant converge times haven't changed much (or at all) with Vagrant 1.7.3 installed.On Fri, Jul 17, 2015 at 4:44 PM, Yoshi Spendiff < " target="_blank"> > wrote:and/or spool up an instance using the chef_zero provider in test kitchen*On Fri, Jul 17, 2015 at 8:41 AM, Yoshi Spendiff < " target="_blank"> > wrote:Out of interest do you get similar times if you spool up a local chef-zero instance and knife upload and/or spool up an instance using the chef_zero provider, just to make sure it's not Vagrant doing something strange?That seems like a long, long time for spooling to me. I used kitchen-ec2 to spool instances on AWS and, granted my cookbook stack is probably smaller than yours, it takes maybe 15-20 minutes to spool an instance (so transferring over the internet).--On Fri, Jul 17, 2015 at 6:48 AM, Greg Damiani < " target="_blank"> > wrote:Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero provisioner that was actually Chef Solo under the covers: https://github.com/mitchellh/vagrant/issues/5072This meant that all your data bags and the code that depended on them had to be fooled, stubbed, or coerced if you wanted to test it in Vagrant. This was generally seen as a bummer and widely regarded as a time sink that produced little business value. "That's what you get for using open source tools, Greg."We'd been waiting for Vagrant 1.7.3 over here for some time because it promised real Chef Zero support: This should have made our hacks and dumb shell scripts obsolete, allowing me to give my dev's a Chef role and nothing else for configuring their development VMs https://github.com/mitchellh/vagrant/pull/5339And so it was like a child starting its first day of school and immediately after dreaming of christmas morning that we watched the above PR get merged and thought to ourselves "probably won't be more than 5 or 6 months before that gets bundled into an official release."Today I can say that this does not fit in our workflow. The Chef Zero provisioner is taking anywhere from 20 to 40 minutes on different laptops just to load our cookbooks into memory from local disk. Then there's the speed at which it seems to be configuring the resources in a run list. I don't have any real figures to refer to, just anecdotal evidence, so I'll resort to hyperbole. Vagrant 1.7.2 and Chef Solo seemed zippy enough. I could spin up a development vagrant machine in about 5-10 minutes depending on role and network. 1.7.3 and Chef Zero are reminiscent of a snail race through knee-deep peanut butter.$ time vagrant provision......wait for it......pain...continue waiting......real 79m59.131suser 0m4.463ssys 0m1.405sSometimes we use Vagrant to test Chef changes locally before uploading to a CI server that will build a branch of chef code on EC2 and run some tests before we mark it as merge-able. I'm telling Chef dev's in this organization that Vagrant is supposed to save them time, that local development is a convenience... and now this. I literally can't even.Who's got a workaround for all these network round trips and molasses uploads? Do I need more ergs? Should I just rub some Docker on it? Aside from declaring 'no joy' and rolling back to Vagrant 1.7.2 what are my options here? We've tried different folder syncing methods (nfs, rsync) and found them all wanting. I'm afraid this is a feature, not a bug:https://github.com/mitchellh/vagrant/issues/5972--Greg Damiani | Senior Kitten Delivery Engineer | @damianigreg
BuzzFeed: The Social News and Entertainment Company
40 Argyll Street, 2nd Floor, London, W1F 7E
--Greg Damiani | Senior System Administrator | @damianigreg
BuzzFeed: The Social News and Entertainment Company
40 Argyll Street, 2nd Floor, London, W1F 7EB
----Greg Damiani | Senior System Administrator | @damianigreg
BuzzFeed: The Social News and Entertainment Company
40 Argyll Street, 2nd Floor, London, W1F 7EB
Archive powered by MHonArc 2.6.16.