What version of ChefDK?
-s
On Fri, Jul 17, 2015 at 12:39 PM, Greg Damiani
< "> > wrote:
> 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
> < "> > 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
>> < "> > 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 < "> >
>>> 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/5072
>>>>
>>>> This 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/5339
>>>>
>>>> -->>>> And 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.131s
>>>> user 0m4.463s
>>>> sys 0m1.405s
>>>>
>>>> Sometimes 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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Yoshi Spendiff
>>> Ops Engineer
>>> Indochino
>>> Mobile: +1 778 952 2025
>>> Email: ">
>>
>>
>>
>>
>> --
>> Yoshi Spendiff
>> Ops Engineer
>> Indochino
>> Mobile: +1 778 952 2025
>> Email: ">
>
>
>
>
> --
>
> 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.