# Vagrant 1.7.3 chef-zero provisioner mostly unusable

**URL:** <https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755>\
**Category:** Chef Infra (archive)\
**Created:** [July 17, 2015, 1:48pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755 "2015-07-17T13:48:54Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Greg\_Damiani](https://avatars.discourse-cdn.com/v4/letter/g/97f17d/32.png) [@Greg\_Damiani](https://discourse.chef.io/u/Greg_Damiani)\
**Post date:** [July 17, 2015, 1:48pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/1 "2015-07-17T13:48:54Z")

</div>

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/hashicorp/vagrant/issues/5072>
>
> Wondering if this is as intended -- it's confusing at least...
> This is my Vagrantfile:
> Vagrant::configure("2") do |config|
> config.vm.define :foo do | foo\_config...

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/hashicorp/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/hashicorp/vagrant/issues/5972>
>
> This was an issue introduced in 1.7.3 and is worked around by downgrading to 1.7.2.
> Chef spends a long time doing this:
> DEBUG...

--

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

---

<div class="post-metadata">

**Author:** ![Yoshi\_Spendiff](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/yoshi_spendiff/32/13_2.png) [@Yoshi\_Spendiff](https://discourse.chef.io/u/Yoshi_Spendiff)\
**Post date:** [July 17, 2015, 3:41pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/2 "2015-07-17T15:41:38Z")

</div>

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 [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
wrote:

> Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> provisioner that was actually Chef Solo under the covers:  
> [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> 
> [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![Yoshi\_Spendiff](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/yoshi_spendiff/32/13_2.png) [@Yoshi\_Spendiff](https://discourse.chef.io/u/Yoshi_Spendiff)\
**Post date:** [July 17, 2015, 3:44pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/3 "2015-07-17T15:44:23Z")

</div>

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 \<  
[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> wrote:
> 
> > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> > provisioner that was actually Chef Solo under the covers:  
> > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > 
> > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)

--  
Yoshi Spendiff  
Ops Engineer  
Indochino  
Mobile: +1 778 952 2025  
Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![Greg\_Damiani](https://avatars.discourse-cdn.com/v4/letter/g/97f17d/32.png) [@Greg\_Damiani](https://discourse.chef.io/u/Greg_Damiani)\
**Post date:** [July 17, 2015, 4:39pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/4 "2015-07-17T16:39:38Z")

</div>

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 \<  
[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> > wrote:
> > 
> > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> > > provisioner that was actually Chef Solo under the covers:  
> > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > 
> > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> 
> --  
> Yoshi Spendiff  
> Ops Engineer  
> Indochino  
> Mobile: +1 778 952 2025  
> Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

--

Greg Damiani | Senior System Administrator | @damianigreg

BuzzFeed: The Social News and Entertainment Company

40 Argyll Street, 2nd Floor, London, W1F 7EB

---

<div class="post-metadata">

**Author:** ![someara](https://avatars.discourse-cdn.com/v4/letter/s/bbe5ce/32.png) [@someara](https://discourse.chef.io/u/someara)\
**Post date:** [July 17, 2015, 5:12pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/5 "2015-07-17T17:12:16Z")

</div>

What version of ChefDK?  
-s

On Fri, Jul 17, 2015 at 12:39 PM, Greg Damiani  
[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com) 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  
> [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) 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  
> > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) 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 [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> > > wrote:
> > > 
> > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> > > > provisioner that was actually Chef Solo under the covers:  
> > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > 
> > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > 
> > --  
> > Yoshi Spendiff  
> > Ops Engineer  
> > Indochino  
> > Mobile: +1 778 952 2025  
> > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> 
> --
> 
> Greg Damiani | Senior System Administrator | @damianigreg
> 
> BuzzFeed: The Social News and Entertainment Company
> 
> 40 Argyll Street, 2nd Floor, London, W1F 7EB

---

<div class="post-metadata">

**Author:** ![Greg\_Damiani](https://avatars.discourse-cdn.com/v4/letter/g/97f17d/32.png) [@Greg\_Damiani](https://discourse.chef.io/u/Greg_Damiani)\
**Post date:** [July 17, 2015, 5:29pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/6 "2015-07-17T17:29:33Z")

</div>

Mac x86\_64 v0.6.2

On Fri, Jul 17, 2015 at 6:12 PM, Sean OMeara [someara@chef.io](mailto:someara@chef.io) wrote:

> What version of ChefDK?  
> -s
> 
> On Fri, Jul 17, 2015 at 12:39 PM, Greg Damiani  
> [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com) 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  
> > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) 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  
> > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) 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 \<  
> > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\>  
> > > > wrote:
> > > > 
> > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> > > > > provisioner that was actually Chef Solo under the covers:  
> > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > 
> > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > 
> > > --  
> > > Yoshi Spendiff  
> > > Ops Engineer  
> > > Indochino  
> > > Mobile: +1 778 952 2025  
> > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > 
> > --
> > 
> > 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

---

<div class="post-metadata">

**Author:** ![Yoshi\_Spendiff](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/yoshi_spendiff/32/13_2.png) [@Yoshi\_Spendiff](https://discourse.chef.io/u/Yoshi_Spendiff)\
**Post date:** [July 17, 2015, 6:06pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/7 "2015-07-17T18:06:37Z")

</div>

Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
converge_ for the same developer on the same machine running the same logic  
path. I.e if you make a .kitchen.yml in the same directory as your  
Vagrantfile and configure kitchen to create an instance in exactly the same  
manner are the times similar or is vagrant slower? In the effort to isolate  
the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is  
actually faster...

There's a couple of interesting things happening in the pipeline to speed  
up test kitchen runs using chef-zero, maybe similar could help you out if  
you're willing to sit out another monkeypatch into merge situation:

> <https://github.com/test-kitchen/test-kitchen/pull/466>
>
> driver: kitchen-ec2
> 
> Before:
> \-----\> Kitchen is finished. (11m53.12s)
> 
> After:
> \---…--\> Kitchen is finished. (0m41.31s)

> <https://github.com/test-kitchen/test-kitchen/pull/620>
>
> The Chef Zero provisioner can run the test client in local
> mode, but when the te…st client is first created and invoked
> it still needs to download cookbooks from the Chef Zero
> server. I have found this initial "Synchronizing Cookbooks"
> to be slow when there are many cookbooks in the test run list.
> 
> This patch copies the cookbooks used to populate the Chef
> Zero server into the kitchen cache directory, which is the
> cache directory of the test client. When the client runs
> its initial "Synchronizing Cookbooks", the cookbooks will
> already be in the cache and the initial synchronization
> will be faster.
> 
> I should add that doing this will increase the size of the
> sandbox needing to be transferred to the remote node.
> Because of this I would recommend that something like
> \#466 is a prerequisite to this, otherwise uploading the
> 
> sandbox to remote provisioners can be prohibitively slow
> (using local provisioners like Vagrant and Docker will
> be faster straight away without needing packaging / 
> compression).

If you're using AWS for spooling instances I also found moving to t2.small  
from t2.micro to be a speed step up.

On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
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 \<  
> [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)
> > > 
> > > > wrote:
> > > 
> > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> > > > provisioner that was actually Chef Solo under the covers:  
> > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > 
> > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > 
> > --  
> > Yoshi Spendiff  
> > Ops Engineer  
> > Indochino  
> > Mobile: +1 778 952 2025  
> > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> 
> --
> 
> 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@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![Greg\_Damiani](https://avatars.discourse-cdn.com/v4/letter/g/97f17d/32.png) [@Greg\_Damiani](https://discourse.chef.io/u/Greg_Damiani)\
**Post date:** [July 20, 2015, 2:01pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/8 "2015-07-20T14:01:13Z")

</div>

I'm seeing the opposite. Same machine, same run\_list. "vagrant up" takes  
about 80 minutes, "kitchen converge" takes 7-8 minutes.

On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:

> Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> converge_ for the same developer on the same machine running the same  
> logic path. I.e if you make a .kitchen.yml in the same directory as your  
> Vagrantfile and configure kitchen to create an instance in exactly the same  
> manner are the times similar or is vagrant slower? In the effort to isolate  
> the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is  
> actually faster...
> 
> There's a couple of interesting things happening in the pipeline to speed  
> up test kitchen runs using chef-zero, maybe similar could help you out if  
> you're willing to sit out another monkeypatch into merge situation:
> 
> [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> 
> If you're using AWS for spooling instances I also found moving to t2.small  
> from t2.micro to be a speed step up.
> 
> On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> 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 \<  
> > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > 
> > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef Zero  
> > > > > provisioner that was actually Chef Solo under the covers:  
> > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > 
> > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > 
> > > --  
> > > Yoshi Spendiff  
> > > Ops Engineer  
> > > Indochino  
> > > Mobile: +1 778 952 2025  
> > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > 
> > --
> > 
> > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)

--

Greg Damiani | Senior System Administrator | @damianigreg

BuzzFeed: The Social News and Entertainment Company

40 Argyll Street, 2nd Floor, London, W1F 7EB

---

<div class="post-metadata">

**Author:** ![Yoshi\_Spendiff](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/yoshi_spendiff/32/13_2.png) [@Yoshi\_Spendiff](https://discourse.chef.io/u/Yoshi_Spendiff)\
**Post date:** [July 20, 2015, 3:00pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/9 "2015-07-20T15:00:39Z")

</div>

Are you using chef\_zero or chef\_solo as your kitchen provisioner?

On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
wrote:

> I'm seeing the opposite. Same machine, same run\_list. "vagrant up" takes  
> about 80 minutes, "kitchen converge" takes 7-8 minutes.
> 
> On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
> [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> 
> > Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> > converge_ for the same developer on the same machine running the same  
> > logic path. I.e if you make a .kitchen.yml in the same directory as your  
> > Vagrantfile and configure kitchen to create an instance in exactly the same  
> > manner are the times similar or is vagrant slower? In the effort to isolate  
> > the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is  
> > actually faster...
> > 
> > There's a couple of interesting things happening in the pipeline to speed  
> > up test kitchen runs using chef-zero, maybe similar could help you out if  
> > you're willing to sit out another monkeypatch into merge situation:
> > 
> > [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> > [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> > 
> > If you're using AWS for spooling instances I also found moving to  
> > t2.small from t2.micro to be a speed step up.
> > 
> > On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> > 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 \<  
> > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > 
> > > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef  
> > > > > > Zero provisioner that was actually Chef Solo under the covers:  
> > > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > > 
> > > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > 
> > > > --  
> > > > Yoshi Spendiff  
> > > > Ops Engineer  
> > > > Indochino  
> > > > Mobile: +1 778 952 2025  
> > > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > 
> > > --
> > > 
> > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> 
> --
> 
> 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@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![Steven\_Murawski](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/steven_murawski/32/1450_2.png) [@Steven\_Murawski](https://discourse.chef.io/u/Steven_Murawski)\
**Post date:** [July 20, 2015, 4:07pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/10 "2015-07-20T16:07:04Z")

</div>

One thing I’ve found, for both Vagrant and any kitchen driver, is making sure my chefignore excludes the .kitchen directory. When Berkshelf scans the cookbook directory, it likes to scan everything, and depending on how much is in your .kitchen folder, that could take a bit. Plus, some drivers have open handles to files (especially on Windows) which can lead to errors.

Steve

Steven Murawski  
Community Software Development Engineer @ Chef  
Microsoft MVP - PowerShell  
[http://stevenmurawski.com](http://stevenmurawski.com) [[http://stevenmurawski.com/](http://stevenmurawski.com/)]  
On 7/20/2015 10:01:03 AM, Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) wrote:  
Are you using chef\_zero or chef\_solo as your kitchen provisioner?

On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani \<[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com) [[mailto:greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)]\> wrote:

I’m seeing the opposite. Same machine, same run\_list. “vagrant up” takes about 80 minutes, “kitchen converge” takes 7-8 minutes.

On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]\> wrote:

Sorry, I mean is it significantly slower to run vagrant up vs kitchen converge for the same developer on the same machine running the same logic path. I.e if you make a .kitchen.yml in the same directory as your Vagrantfile and configure kitchen to create an instance in exactly the same manner are the times similar or is vagrant slower? In the effort to isolate the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is actually faster…

There’s a couple of interesting things happening in the pipeline to speed up test kitchen runs using chef-zero, maybe similar could help you out if you’re willing to sit out another monkeypatch into merge situation:

[https://github.com/test-kitchen/test-kitchen/pull/466](https://github.com/test-kitchen/test-kitchen/pull/466) [[https://github.com/test-kitchen/test-kitchen/pull/466](https://github.com/test-kitchen/test-kitchen/pull/466)]  
[https://github.com/test-kitchen/test-kitchen/pull/620](https://github.com/test-kitchen/test-kitchen/pull/620) [[https://github.com/test-kitchen/test-kitchen/pull/620](https://github.com/test-kitchen/test-kitchen/pull/620)]

If you’re using AWS for spooling instances I also found moving to t2.small from t2.micro to be a speed step up.

On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani \<[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com) [[mailto:greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)]\> 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 \<[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]\> 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 \<[yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]\> 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 \<[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com) [[mailto:greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)]\> 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](https://github.com/mitchellh/vagrant/issues/5072) [[https://github.com/mitchellh/vagrant/issues/5072](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](https://github.com/mitchellh/vagrant/pull/5339) [[https://github.com/mitchellh/vagrant/pull/5339](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](https://github.com/mitchellh/vagrant/issues/5972) [[https://github.com/mitchellh/vagrant/issues/5972](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 [tel:%2B1%20778%20952%202025]  
Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]

–

Yoshi Spendiff  
Ops Engineer  
Indochino  
Mobile: +1 778 952 2025 [tel:%2B1%20778%20952%202025]  
Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]

–

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 [tel:%2B1%20778%20952%202025]  
Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]

–

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@indochino.com](mailto:yoshi.spendiff@indochino.com) [[mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)]

---

<div class="post-metadata">

**Author:** ![Christine\_Draper](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/christine_draper/32/68_2.png) [@Christine\_Draper](https://discourse.chef.io/u/Christine_Draper)\
**Post date:** [July 22, 2015, 1:29pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/11 "2015-07-22T13:29:52Z")

</div>

I've been experiencing a similar problem on one of my machines (Windows  
8.1) in a slightly different setup - using chef-zero standalone to  
bootstrap VMs that I've created using vagrant.

If I run chef-zero on either a host private network (e.g. using -H10.0.1.1)  
or on localhost (default), berkps upload perhaps loads a cookbook every  
10-20 seconds. If I instead use the public IP of the host, it takes 1 sec  
or less per cookbook.

I'm pretty sure this is a problem with my network setup (e.g. routing  
internal traffic wrong), just haven't had the motivation/ergs to figure out  
what, given I have the workaround of using my public IP address. I only  
mention this in case it helps suggest what might be going wrong for Greg's  
case. Of course, I wouldn't be sad if it helped me figure out my issue too!

Regards,  
Christine

On Mon, Jul 20, 2015 at 11:07 AM, Steven Murawski \<[steven.murawski@gmail.com](mailto:steven.murawski@gmail.com)

> wrote:

> One thing I've found, for both Vagrant and any kitchen driver, is making  
> sure my chefignore excludes the .kitchen directory. When Berkshelf scans  
> the cookbook directory, it likes to scan everything, and depending on how  
> much is in your .kitchen folder, that could take a bit. Plus, some drivers  
> have open handles to files (especially on Windows) which can lead to errors.
> 
> Steve
> 
> Steven Murawski  
> Community Software Development Engineer @ Chef  
> Microsoft MVP - PowerShell  
> [http://stevenmurawski.com](http://stevenmurawski.com)
> 
> On 7/20/2015 10:01:03 AM, Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)  
> wrote:  
> Are you using chef\_zero or chef\_solo as your kitchen provisioner?
> 
> On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> wrote:
> 
> > I'm seeing the opposite. Same machine, same run\_list. "vagrant up"  
> > takes about 80 minutes, "kitchen converge" takes 7-8 minutes.
> > 
> > On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
> > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> > 
> > > Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> > > converge_ for the same developer on the same machine running the same  
> > > logic path. I.e if you make a .kitchen.yml in the same directory as your  
> > > Vagrantfile and configure kitchen to create an instance in exactly the same  
> > > manner are the times similar or is vagrant slower? In the effort to isolate  
> > > the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is  
> > > actually faster...
> > > 
> > > There's a couple of interesting things happening in the pipeline to  
> > > speed up test kitchen runs using chef-zero, maybe similar could help you  
> > > out if you're willing to sit out another monkeypatch into merge situation:
> > > 
> > > [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> > > [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> > > 
> > > If you're using AWS for spooling instances I also found moving to  
> > > t2.small from t2.micro to be a speed step up.
> > > 
> > > On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani \<[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)
> > > 
> > > > 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 \<  
> > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > > 
> > > > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef  
> > > > > > > Zero provisioner that was actually Chef Solo under the covers:  
> > > > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > > > 
> > > > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > 
> > > > > --  
> > > > > Yoshi Spendiff  
> > > > > Ops Engineer  
> > > > > Indochino  
> > > > > Mobile: +1 778 952 2025  
> > > > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > 
> > > > --
> > > > 
> > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > 
> > --
> > 
> > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)

--  
ThirdWave Insights, LLC I (512) 971-8727 \<%28512%29%20656-7724\> I  
[www.ThirdWaveInsights.com](http://www.ThirdWaveInsights.com) I P.O. Box 500134 I Austin, TX 78750

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [August 9, 2015, 10:12pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/12 "2015-08-09T22:12:07Z")

</div>

I was experiencing extremely slow chef runs as well with vagrant 1.7.4 and  
the chef\_zero provisioner.

It turned out to be vagrant-cachier in my case, which caches  
"/var/chef/cache" [0] where chef\_zero also stores it's cookbooks  
internally. Having vagrant-cachier caching these file by file was super  
slow, even with only a minimum set of cookbooks...

Actually I find it quite useful to cache "/var/chef/cache".

Is there an option in chef\_zero config to store the cookbooks anywhere  
outside the file\_cache\_path?

Cheers, Torben

[0] [http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/](http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/)

On Wed, Jul 22, 2015 at 3:29 PM, Christine Draper \<  
[christine\_draper@thirdwaveinsights.com](mailto:christine_draper@thirdwaveinsights.com)\> wrote:

> I've been experiencing a similar problem on one of my machines (Windows  
> 8.1) in a slightly different setup - using chef-zero standalone to  
> bootstrap VMs that I've created using vagrant.
> 
> If I run chef-zero on either a host private network (e.g. using  
> -H10.0.1.1) or on localhost (default), berkps upload perhaps loads a  
> cookbook every 10-20 seconds. If I instead use the public IP of the host,  
> it takes 1 sec or less per cookbook.
> 
> I'm pretty sure this is a problem with my network setup (e.g. routing  
> internal traffic wrong), just haven't had the motivation/ergs to figure out  
> what, given I have the workaround of using my public IP address. I only  
> mention this in case it helps suggest what might be going wrong for Greg's  
> case. Of course, I wouldn't be sad if it helped me figure out my issue too!
> 
> Regards,  
> Christine
> 
> On Mon, Jul 20, 2015 at 11:07 AM, Steven Murawski \<  
> [steven.murawski@gmail.com](mailto:steven.murawski@gmail.com)\> wrote:
> 
> > One thing I've found, for both Vagrant and any kitchen driver, is making  
> > sure my chefignore excludes the .kitchen directory. When Berkshelf scans  
> > the cookbook directory, it likes to scan everything, and depending on how  
> > much is in your .kitchen folder, that could take a bit. Plus, some drivers  
> > have open handles to files (especially on Windows) which can lead to errors.
> > 
> > Steve
> > 
> > Steven Murawski  
> > Community Software Development Engineer @ Chef  
> > Microsoft MVP - PowerShell  
> > [http://stevenmurawski.com](http://stevenmurawski.com)
> > 
> > On 7/20/2015 10:01:03 AM, Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)  
> > wrote:  
> > Are you using chef\_zero or chef\_solo as your kitchen provisioner?
> > 
> > On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)  
> > wrote:
> > 
> > > I'm seeing the opposite. Same machine, same run\_list. "vagrant up"  
> > > takes about 80 minutes, "kitchen converge" takes 7-8 minutes.
> > > 
> > > On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
> > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> > > 
> > > > Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> > > > converge_ for the same developer on the same machine running the same  
> > > > logic path. I.e if you make a .kitchen.yml in the same directory as your  
> > > > Vagrantfile and configure kitchen to create an instance in exactly the same  
> > > > manner are the times similar or is vagrant slower? In the effort to isolate  
> > > > the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is  
> > > > actually faster...
> > > > 
> > > > There's a couple of interesting things happening in the pipeline to  
> > > > speed up test kitchen runs using chef-zero, maybe similar could help you  
> > > > out if you're willing to sit out another monkeypatch into merge situation:
> > > > 
> > > > [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> > > > [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> > > > 
> > > > If you're using AWS for spooling instances I also found moving to  
> > > > t2.small from t2.micro to be a speed step up.
> > > > 
> > > > On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani \<  
> > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> 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 \<  
> > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > > > 
> > > > > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef  
> > > > > > > > Zero provisioner that was actually Chef Solo under the covers:  
> > > > > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > > > > 
> > > > > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > 
> > > > > > --  
> > > > > > Yoshi Spendiff  
> > > > > > Ops Engineer  
> > > > > > Indochino  
> > > > > > Mobile: +1 778 952 2025  
> > > > > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > 
> > > > > --
> > > > > 
> > > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > 
> > > --
> > > 
> > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> 
> --  
> ThirdWave Insights, LLC I (512) 971-8727 \<%28512%29%20656-7724\> I  
> [www.ThirdWaveInsights.com](http://www.ThirdWaveInsights.com) I P.O. Box 500134 I Austin, TX 78750

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [August 9, 2015, 10:43pm UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/13 "2015-08-09T22:43:23Z")

</div>

Ooops I was wrong: it was vagrant-cachier which made the situation actually  
a bit better. With cachier disabled it happens now every run, not only the  
first one.

Thought that these messages came from cachier, but it was chef-zero indeed?

...  
==\> sample-app: resolving cookbooks for run list: ["sample-app"]  
==\> sample-app: [2015-08-09T22:36:17+00:00] INFO: Loading cookbooks  
[sample-app@0.2.1, apache2@3.0.1, apt@2.7.0, iptables@1.0.0, logrotate@1.9.1  
]  
==\> sample-app: Synchronizing cookbooks  
==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
cookbooks/sample-app/.rubocop.yml in the cache.  
==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
cookbooks/sample-app/Berksfile in the cache.  
==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
cookbooks/sample-app/Berksfile.lock in the cache.  
==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
cookbooks/sample-app/CHANGELOG.md in the cache.  
==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
cookbooks/sample-app/.kitchen.lxc.yml in the cache.  
==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
cookbooks/sample-app/attributes/default.rb in the cache.  
==\> sample-app: [2015-08-09T22:36:22+00:00] INFO: Storing updated  
cookbooks/sample-app/templates/default/sample.html.erb in the cache.  
==\> sample-app: [2015-08-09T22:36:22+00:00] INFO: Storing updated  
cookbooks/sample-app/recipes/default.rb in the cache.  
...

With all the dependent cookbooks the "Synchronizing cookbooks" takes quite  
an amount of extra time (~4 minutes for apt, apache2, iptables, logrotate)

Would be great if there were a way to disable "Synchronizing cookbooks" for  
the vagrant case, because the cookbooks are mounted via synced\_folder  
anyway, so there is no need for caching it internally

Any ideas?

Cheers, Torben

On Mon, Aug 10, 2015 at 12:12 AM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:

> I was experiencing extremely slow chef runs as well with vagrant 1.7.4 and  
> the chef\_zero provisioner.
> 
> It turned out to be vagrant-cachier in my case, which caches  
> "/var/chef/cache" [0] where chef\_zero also stores it's cookbooks  
> internally. Having vagrant-cachier caching these file by file was super  
> slow, even with only a minimum set of cookbooks...
> 
> Actually I find it quite useful to cache "/var/chef/cache".
> 
> Is there an option in chef\_zero config to store the cookbooks anywhere  
> outside the file\_cache\_path?
> 
> Cheers, Torben
> 
> [0] [http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/](http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/)
> 
> On Wed, Jul 22, 2015 at 3:29 PM, Christine Draper \<  
> [christine\_draper@thirdwaveinsights.com](mailto:christine_draper@thirdwaveinsights.com)\> wrote:
> 
> > I've been experiencing a similar problem on one of my machines (Windows  
> > 8.1) in a slightly different setup - using chef-zero standalone to  
> > bootstrap VMs that I've created using vagrant.
> > 
> > If I run chef-zero on either a host private network (e.g. using  
> > -H10.0.1.1) or on localhost (default), berkps upload perhaps loads a  
> > cookbook every 10-20 seconds. If I instead use the public IP of the host,  
> > it takes 1 sec or less per cookbook.
> > 
> > I'm pretty sure this is a problem with my network setup (e.g. routing  
> > internal traffic wrong), just haven't had the motivation/ergs to figure out  
> > what, given I have the workaround of using my public IP address. I only  
> > mention this in case it helps suggest what might be going wrong for Greg's  
> > case. Of course, I wouldn't be sad if it helped me figure out my issue too!
> > 
> > Regards,  
> > Christine
> > 
> > On Mon, Jul 20, 2015 at 11:07 AM, Steven Murawski \<  
> > [steven.murawski@gmail.com](mailto:steven.murawski@gmail.com)\> wrote:
> > 
> > > One thing I've found, for both Vagrant and any kitchen driver, is making  
> > > sure my chefignore excludes the .kitchen directory. When Berkshelf scans  
> > > the cookbook directory, it likes to scan everything, and depending on how  
> > > much is in your .kitchen folder, that could take a bit. Plus, some drivers  
> > > have open handles to files (especially on Windows) which can lead to errors.
> > > 
> > > Steve
> > > 
> > > Steven Murawski  
> > > Community Software Development Engineer @ Chef  
> > > Microsoft MVP - PowerShell  
> > > [http://stevenmurawski.com](http://stevenmurawski.com)
> > > 
> > > On 7/20/2015 10:01:03 AM, Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)  
> > > wrote:  
> > > Are you using chef\_zero or chef\_solo as your kitchen provisioner?
> > > 
> > > On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani \<[greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)
> > > 
> > > > wrote:
> > > 
> > > > I'm seeing the opposite. Same machine, same run\_list. "vagrant up"  
> > > > takes about 80 minutes, "kitchen converge" takes 7-8 minutes.
> > > > 
> > > > On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
> > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> > > > 
> > > > > Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> > > > > converge_ for the same developer on the same machine running the same  
> > > > > logic path. I.e if you make a .kitchen.yml in the same directory as your  
> > > > > Vagrantfile and configure kitchen to create an instance in exactly the same  
> > > > > manner are the times similar or is vagrant slower? In the effort to isolate  
> > > > > the problem, being file transfer, Vagrant or chef-zero. For me Vagrant is  
> > > > > actually faster...
> > > > > 
> > > > > There's a couple of interesting things happening in the pipeline to  
> > > > > speed up test kitchen runs using chef-zero, maybe similar could help you  
> > > > > out if you're willing to sit out another monkeypatch into merge situation:
> > > > > 
> > > > > [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> > > > > [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> > > > > 
> > > > > If you're using AWS for spooling instances I also found moving to  
> > > > > t2.small from t2.micro to be a speed step up.
> > > > > 
> > > > > On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani \<  
> > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> 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 \<  
> > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > > > > 
> > > > > > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef  
> > > > > > > > > Zero provisioner that was actually Chef Solo under the covers:  
> > > > > > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > > > > > 
> > > > > > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > > 
> > > > > > > --  
> > > > > > > Yoshi Spendiff  
> > > > > > > Ops Engineer  
> > > > > > > Indochino  
> > > > > > > Mobile: +1 778 952 2025  
> > > > > > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > 
> > > > > > --
> > > > > > 
> > > > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > 
> > > > --
> > > > 
> > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > 
> > --  
> > ThirdWave Insights, LLC I (512) 971-8727 \<%28512%29%20656-7724\> I  
> > [www.ThirdWaveInsights.com](http://www.ThirdWaveInsights.com) I P.O. Box 500134 I Austin, TX 78750

---

<div class="post-metadata">

**Author:** ![someara](https://avatars.discourse-cdn.com/v4/letter/s/bbe5ce/32.png) [@someara](https://discourse.chef.io/u/someara)\
**Post date:** [August 10, 2015, 3:19am UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/14 "2015-08-10T03:19:38Z")

</div>

I don't use Vagrant, but I have noticed that "synchronizing cookbooks"  
takes a while lately..

What version of chef-client did "synchronizing cookbooks" start taking  
forever?

-s

On Sun, Aug 9, 2015 at 6:43 PM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:

> Ooops I was wrong: it was vagrant-cachier which made the situation  
> actually a bit better. With cachier disabled it happens now every run, not  
> only the first one.
> 
> Thought that these messages came from cachier, but it was chef-zero indeed?
> 
> ...  
> ==\> sample-app: resolving cookbooks for run list: ["sample-app"]  
> ==\> sample-app: [2015-08-09T22:36:17+00:00] INFO: Loading cookbooks  
> [sample-app@0.2.1, apache2@3.0.1, apt@2.7.0, iptables@1.0.0,  
> logrotate@1.9.1]  
> ==\> sample-app: Synchronizing cookbooks  
> ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> cookbooks/sample-app/.rubocop.yml in the cache.  
> ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> cookbooks/sample-app/Berksfile in the cache.  
> ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> cookbooks/sample-app/Berksfile.lock in the cache.  
> ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> cookbooks/sample-app/CHANGELOG.md in the cache.  
> ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> cookbooks/sample-app/.kitchen.lxc.yml in the cache.  
> ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> cookbooks/sample-app/attributes/default.rb in the cache.  
> ==\> sample-app: [2015-08-09T22:36:22+00:00] INFO: Storing updated  
> cookbooks/sample-app/templates/default/sample.html.erb in the cache.  
> ==\> sample-app: [2015-08-09T22:36:22+00:00] INFO: Storing updated  
> cookbooks/sample-app/recipes/default.rb in the cache.  
> ...
> 
> With all the dependent cookbooks the "Synchronizing cookbooks" takes quite  
> an amount of extra time (~4 minutes for apt, apache2, iptables, logrotate)
> 
> Would be great if there were a way to disable "Synchronizing cookbooks"  
> for the vagrant case, because the cookbooks are mounted via synced\_folder  
> anyway, so there is no need for caching it internally
> 
> Any ideas?
> 
> Cheers, Torben
> 
> On Mon, Aug 10, 2015 at 12:12 AM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:
> 
> > I was experiencing extremely slow chef runs as well with vagrant 1.7.4  
> > and the chef\_zero provisioner.
> > 
> > It turned out to be vagrant-cachier in my case, which caches  
> > "/var/chef/cache" [0] where chef\_zero also stores it's cookbooks  
> > internally. Having vagrant-cachier caching these file by file was super  
> > slow, even with only a minimum set of cookbooks...
> > 
> > Actually I find it quite useful to cache "/var/chef/cache".
> > 
> > Is there an option in chef\_zero config to store the cookbooks anywhere  
> > outside the file\_cache\_path?
> > 
> > Cheers, Torben
> > 
> > [0] [http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/](http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/)
> > 
> > On Wed, Jul 22, 2015 at 3:29 PM, Christine Draper \<  
> > [christine\_draper@thirdwaveinsights.com](mailto:christine_draper@thirdwaveinsights.com)\> wrote:
> > 
> > > I've been experiencing a similar problem on one of my machines (Windows  
> > > 8.1) in a slightly different setup - using chef-zero standalone to  
> > > bootstrap VMs that I've created using vagrant.
> > > 
> > > If I run chef-zero on either a host private network (e.g. using  
> > > -H10.0.1.1) or on localhost (default), berkps upload perhaps loads a  
> > > cookbook every 10-20 seconds. If I instead use the public IP of the host,  
> > > it takes 1 sec or less per cookbook.
> > > 
> > > I'm pretty sure this is a problem with my network setup (e.g. routing  
> > > internal traffic wrong), just haven't had the motivation/ergs to figure out  
> > > what, given I have the workaround of using my public IP address. I only  
> > > mention this in case it helps suggest what might be going wrong for Greg's  
> > > case. Of course, I wouldn't be sad if it helped me figure out my issue too!
> > > 
> > > Regards,  
> > > Christine
> > > 
> > > On Mon, Jul 20, 2015 at 11:07 AM, Steven Murawski \<  
> > > [steven.murawski@gmail.com](mailto:steven.murawski@gmail.com)\> wrote:
> > > 
> > > > One thing I've found, for both Vagrant and any kitchen driver, is  
> > > > making sure my chefignore excludes the .kitchen directory. When Berkshelf  
> > > > scans the cookbook directory, it likes to scan everything, and depending on  
> > > > how much is in your .kitchen folder, that could take a bit. Plus, some  
> > > > drivers have open handles to files (especially on Windows) which can lead  
> > > > to errors.
> > > > 
> > > > Steve
> > > > 
> > > > Steven Murawski  
> > > > Community Software Development Engineer @ Chef  
> > > > Microsoft MVP - PowerShell  
> > > > [http://stevenmurawski.com](http://stevenmurawski.com)
> > > > 
> > > > On 7/20/2015 10:01:03 AM, Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)  
> > > > wrote:  
> > > > Are you using chef\_zero or chef\_solo as your kitchen provisioner?
> > > > 
> > > > On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani \<  
> > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > 
> > > > > I'm seeing the opposite. Same machine, same run\_list. "vagrant up"  
> > > > > takes about 80 minutes, "kitchen converge" takes 7-8 minutes.
> > > > > 
> > > > > On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
> > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> > > > > 
> > > > > > Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> > > > > > converge_ for the same developer on the same machine running the  
> > > > > > same logic path. I.e if you make a .kitchen.yml in the same directory as  
> > > > > > your Vagrantfile and configure kitchen to create an instance in exactly the  
> > > > > > same manner are the times similar or is vagrant slower? In the effort to  
> > > > > > isolate the problem, being file transfer, Vagrant or chef-zero. For me  
> > > > > > Vagrant is actually faster...
> > > > > > 
> > > > > > There's a couple of interesting things happening in the pipeline to  
> > > > > > speed up test kitchen runs using chef-zero, maybe similar could help you  
> > > > > > out if you're willing to sit out another monkeypatch into merge situation:
> > > > > > 
> > > > > > [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> > > > > > [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> > > > > > 
> > > > > > If you're using AWS for spooling instances I also found moving to  
> > > > > > t2.small from t2.micro to be a speed step up.
> > > > > > 
> > > > > > On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani \<  
> > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> 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 \<  
> > > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > > > > > 
> > > > > > > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged Chef  
> > > > > > > > > > Zero provisioner that was actually Chef Solo under the covers:  
> > > > > > > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > > > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > > > > > > 
> > > > > > > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > > > 
> > > > > > > > --  
> > > > > > > > Yoshi Spendiff  
> > > > > > > > Ops Engineer  
> > > > > > > > Indochino  
> > > > > > > > Mobile: +1 778 952 2025  
> > > > > > > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > > 
> > > > > > > --
> > > > > > > 
> > > > > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > 
> > > > > --
> > > > > 
> > > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > 
> > > --  
> > > ThirdWave Insights, LLC I (512) 971-8727 \<%28512%29%20656-7724\> I  
> > > [www.ThirdWaveInsights.com](http://www.ThirdWaveInsights.com) I P.O. Box 500134 I Austin, TX 78750

---

<div class="post-metadata">

**Author:** ![tknerr](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tknerr/32/21_2.png) [@tknerr](https://discourse.chef.io/u/tknerr)\
**Post date:** [August 10, 2015, 7:22am UTC](https://discourse.chef.io/t/vagrant-1-7-3-chef-zero-provisioner-mostly-unusable/6755/15 "2015-08-10T07:22:53Z")

</div>

12.3.0 that was.

So it's chef-client filling it's cache rather than the in-memory chef-zero?

Cheers, Torben  
Am 10.08.2015 05:19 schrieb "Sean OMeara" [someara@chef.io](mailto:someara@chef.io):

> I don't use Vagrant, but I have noticed that "synchronizing cookbooks"  
> takes a while lately..
> 
> What version of chef-client did "synchronizing cookbooks" start taking  
> forever?
> 
> -s
> 
> On Sun, Aug 9, 2015 at 6:43 PM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:
> 
> > Ooops I was wrong: it was vagrant-cachier which made the situation  
> > actually a bit better. With cachier disabled it happens now every run, not  
> > only the first one.
> > 
> > Thought that these messages came from cachier, but it was chef-zero  
> > indeed?
> > 
> > ...  
> > ==\> sample-app: resolving cookbooks for run list: ["sample-app"]  
> > ==\> sample-app: [2015-08-09T22:36:17+00:00] INFO: Loading cookbooks  
> > [sample-app@0.2.1, apache2@3.0.1, apt@2.7.0, iptables@1.0.0,  
> > logrotate@1.9.1]  
> > ==\> sample-app: Synchronizing cookbooks  
> > ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> > cookbooks/sample-app/.rubocop.yml in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> > cookbooks/sample-app/Berksfile in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> > cookbooks/sample-app/Berksfile.lock in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> > cookbooks/sample-app/CHANGELOG.md in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> > cookbooks/sample-app/.kitchen.lxc.yml in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:21+00:00] INFO: Storing updated  
> > cookbooks/sample-app/attributes/default.rb in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:22+00:00] INFO: Storing updated  
> > cookbooks/sample-app/templates/default/sample.html.erb in the cache.  
> > ==\> sample-app: [2015-08-09T22:36:22+00:00] INFO: Storing updated  
> > cookbooks/sample-app/recipes/default.rb in the cache.  
> > ...
> > 
> > With all the dependent cookbooks the "Synchronizing cookbooks" takes  
> > quite an amount of extra time (~4 minutes for apt, apache2, iptables,  
> > logrotate)
> > 
> > Would be great if there were a way to disable "Synchronizing cookbooks"  
> > for the vagrant case, because the cookbooks are mounted via synced\_folder  
> > anyway, so there is no need for caching it internally
> > 
> > Any ideas?
> > 
> > Cheers, Torben
> > 
> > On Mon, Aug 10, 2015 at 12:12 AM, Torben Knerr [mail@tknerr.de](mailto:mail@tknerr.de) wrote:
> > 
> > > I was experiencing extremely slow chef runs as well with vagrant 1.7.4  
> > > and the chef\_zero provisioner.
> > > 
> > > It turned out to be vagrant-cachier in my case, which caches  
> > > "/var/chef/cache" [0] where chef\_zero also stores it's cookbooks  
> > > internally. Having vagrant-cachier caching these file by file was super  
> > > slow, even with only a minimum set of cookbooks...
> > > 
> > > Actually I find it quite useful to cache "/var/chef/cache".
> > > 
> > > Is there an option in chef\_zero config to store the cookbooks anywhere  
> > > outside the file\_cache\_path?
> > > 
> > > Cheers, Torben
> > > 
> > > [0] [http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/](http://fgrehm.viewdocs.io/vagrant-cachier/buckets/chef/)
> > > 
> > > On Wed, Jul 22, 2015 at 3:29 PM, Christine Draper \<  
> > > [christine\_draper@thirdwaveinsights.com](mailto:christine_draper@thirdwaveinsights.com)\> wrote:
> > > 
> > > > I've been experiencing a similar problem on one of my machines (Windows  
> > > > 8.1) in a slightly different setup - using chef-zero standalone to  
> > > > bootstrap VMs that I've created using vagrant.
> > > > 
> > > > If I run chef-zero on either a host private network (e.g. using  
> > > > -H10.0.1.1) or on localhost (default), berkps upload perhaps loads a  
> > > > cookbook every 10-20 seconds. If I instead use the public IP of the host,  
> > > > it takes 1 sec or less per cookbook.
> > > > 
> > > > I'm pretty sure this is a problem with my network setup (e.g. routing  
> > > > internal traffic wrong), just haven't had the motivation/ergs to figure out  
> > > > what, given I have the workaround of using my public IP address. I only  
> > > > mention this in case it helps suggest what might be going wrong for Greg's  
> > > > case. Of course, I wouldn't be sad if it helped me figure out my issue too!
> > > > 
> > > > Regards,  
> > > > Christine
> > > > 
> > > > On Mon, Jul 20, 2015 at 11:07 AM, Steven Murawski \<  
> > > > [steven.murawski@gmail.com](mailto:steven.murawski@gmail.com)\> wrote:
> > > > 
> > > > > One thing I've found, for both Vagrant and any kitchen driver, is  
> > > > > making sure my chefignore excludes the .kitchen directory. When Berkshelf  
> > > > > scans the cookbook directory, it likes to scan everything, and depending on  
> > > > > how much is in your .kitchen folder, that could take a bit. Plus, some  
> > > > > drivers have open handles to files (especially on Windows) which can lead  
> > > > > to errors.
> > > > > 
> > > > > Steve
> > > > > 
> > > > > Steven Murawski  
> > > > > Community Software Development Engineer @ Chef  
> > > > > Microsoft MVP - PowerShell  
> > > > > [http://stevenmurawski.com](http://stevenmurawski.com)
> > > > > 
> > > > > On 7/20/2015 10:01:03 AM, Yoshi Spendiff [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)  
> > > > > wrote:  
> > > > > Are you using chef\_zero or chef\_solo as your kitchen provisioner?
> > > > > 
> > > > > On Mon, Jul 20, 2015 at 7:01 AM, Greg Damiani \<  
> > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > 
> > > > > > I'm seeing the opposite. Same machine, same run\_list. "vagrant up"  
> > > > > > takes about 80 minutes, "kitchen converge" takes 7-8 minutes.
> > > > > > 
> > > > > > On Fri, Jul 17, 2015 at 7:06 PM, Yoshi Spendiff \<  
> > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> wrote:
> > > > > > 
> > > > > > > Sorry, I mean is it significantly slower to run \*vagrant up \*vs _kitchen  
> > > > > > > converge_ for the same developer on the same machine running the  
> > > > > > > same logic path. I.e if you make a .kitchen.yml in the same directory as  
> > > > > > > your Vagrantfile and configure kitchen to create an instance in exactly the  
> > > > > > > same manner are the times similar or is vagrant slower? In the effort to  
> > > > > > > isolate the problem, being file transfer, Vagrant or chef-zero. For me  
> > > > > > > Vagrant is actually faster...
> > > > > > > 
> > > > > > > There's a couple of interesting things happening in the pipeline to  
> > > > > > > speed up test kitchen runs using chef-zero, maybe similar could help you  
> > > > > > > out if you're willing to sit out another monkeypatch into merge situation:
> > > > > > > 
> > > > > > > [Add compression before uploading files by NikolayMurha · Pull Request #466 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/466)  
> > > > > > > [Populate Chef Zero provisioner cookbook cache by pleary · Pull Request #620 · test-kitchen/test-kitchen · GitHub](https://github.com/test-kitchen/test-kitchen/pull/620)
> > > > > > > 
> > > > > > > If you're using AWS for spooling instances I also found moving to  
> > > > > > > t2.small from t2.micro to be a speed step up.
> > > > > > > 
> > > > > > > On Fri, Jul 17, 2015 at 9:39 AM, Greg Damiani \<  
> > > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> 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 \<  
> > > > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > > > [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)\> 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 \<  
> > > > > > > > > > [greg.damiani@buzzfeed.com](mailto:greg.damiani@buzzfeed.com)\> wrote:
> > > > > > > > > > 
> > > > > > > > > > > Previous versions of Vagrant (1.7.2 and prior) used a fudged  
> > > > > > > > > > > Chef Zero provisioner that was actually Chef Solo under the covers:  
> > > > > > > > > > > [Chef Zero Provisioner reports itself as being Chef Solo? · Issue #5072 · hashicorp/vagrant · GitHub](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  
> > > > > > > > > > > [Chef Provisioner : Support real chef-zero/local mode by YpNo · Pull Request #5339 · hashicorp/vagrant · GitHub](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:
> > > > > > > > > > > 
> > > > > > > > > > > [chef-zero provisioner spends a long time synchronizing cookbooks · Issue #5972 · hashicorp/vagrant · GitHub](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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > > > > 
> > > > > > > > > --  
> > > > > > > > > Yoshi Spendiff  
> > > > > > > > > Ops Engineer  
> > > > > > > > > Indochino  
> > > > > > > > > Mobile: +1 778 952 2025  
> > > > > > > > > Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > > > 
> > > > > > > > --
> > > > > > > > 
> > > > > > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > > > 
> > > > > > --
> > > > > > 
> > > > > > 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@indochino.com](mailto:yoshi.spendiff@indochino.com)
> > > > 
> > > > --  
> > > > ThirdWave Insights, LLC I (512) 971-8727 \<%28512%29%20656-7724\> I  
> > > > [www.ThirdWaveInsights.com](http://www.ThirdWaveInsights.com) I P.O. Box 500134 I Austin, TX 78750