Don't get me wrong. I <3 Vagrant. I use it all the time and for every project. My new MacBook Air is as pristine as the day I got it. But, Vagrant is not the ultimate solution for me. I don't think it exists, of course. My wish list is too long but...
I want something that:
1) Runs completely locally. I want to be able to work offline, on a plane, whatever without needing remote resources.
2) Minimizes dependencies. Adding chef cookbook servers, apt-get, etc. into the mix is another point of failure.
3) Is scalable/reusable. Most people/companies have multiple projects they work on and much of the vagrant/(chef|puppet) architecture doesn't easily support diverse workloads (this project needs recipes x,y,z, this one needs a,b,x,y; this server runs ubuntu 10.10, the other 10.04)
4) Is all integrated. Sure, I can use some combination of chef, chef-knife, and chef-librarian but they don't work together in my project. Someone can check in a new project setting and unless I run vagrant up, it'll continue to run happily. I want something like bundler that will fail to run unless I'm all up to date, and is unified into a single package.
Given those restrictions, here's what bothers me about the vagrant ecosystem (they're not really complaints about Vagrant per-se but the state of dev virtualization):
1) Every project I get needs a VM (unless I want to start installing stuff locally). This increases the amount of time it takes to get a project up and running. Yes, in the long run it pays off, but can be a barrier to entry for "I just want to fork a project for a quick bug fix".
2) VirtualBox building is slow, takes forever, and requires gobs of disk space. If I have 4 projects, it seems I need a separate vbox for each one. Now I've got GBs of files littering my filesystem. I'd kill for dedupe.
3) Chef / Puppet recipes are one-size-fits-all, and to change them requires adding a whole lot of infrastructure. Sure, you can embed them in your project (chef-solo), but then that's not very reusable.
So you can set up your own chef cookbook server, but then it's another moving part that can fail and then no one can provision new VMs. Bleh. We've gone with symlinking our own cookbook repo into our projects. That's suboptimal but avoids a whole lot of yak shaving.
What I'd like are more extensible cookbooks that have per-project configuration. Yes, they often have some configurable values, but occasionally I want to use a cookbook but it's got some strange version of a lib in there that is incredibly out of date that I can't change.
