Vagrant core no longer tied to VirtualBox

Vagrant author here. Allow me to address both of your points.

First, the "Java-ish" Ruby: I am using the middleware pattern. The classes are used to build up complex sequences of actions[1]. They are reusable and very easily testable. Why classes? Why not modules with functions? It actually started out as modules with functions, but middleware was so _painfully_ the RIGHT way to do things, I can't imagine doing it any other way. Instead of explaining it all, I guide you to this talk I gave on the pattern: http://confreaks.com/videos/961-mwrc2012-rack-middleware-as-...

Next, on Vagrant being "overkill." Write a shell script that does the following: Import a virtual machine, setup host only networking, setup shared folders, boots the machine, runs a provisioner within the machine. Wow that is simple. Oh, wait, I need that script to work on Mac, Linux, and Windows. Oh, VirtualBox has some bugs so can you work around that?[2] Also, host only networking requires some guest OS specific setup (Ubuntu different from Fedora different from FreeBSD etc.), so you have to handle that. Right, and it'd be nice if the script didn't setup networking that collided with other machines on the network, so please write in checks that ports and IPs don't collide. Maybe the script should also verify that Guest Additions are properly installed. AND shared folder performance in VirtualBox sucks, so can you modify that script to use NFS? But only on non-Windows, because Windows doesn't support NFS. Did I mention that NFS requires specialized configuration depending on the host OS AND guest OS? So if you're running Mac + Ubuntu its totally different from Linux + FreeBSD. Have fun!

Now, make all of that REUSABLE and EXTENSIBLE, while adding in some other features (other types of networking, host name setting, and so on).

Yeah, I'd say Vagrant's 3000 line of code count is pretty spot on, and pretty good.

[1]: https://github.com/mitchellh/vagrant/blob/391dc392675c73518e...

[2]: https://github.com/mitchellh/vagrant/blob/391dc392675c73518e...

Vagrant author here.

Files in lib/ (core): 71

Files in plugin/: 142

Total: 213.

Still a lot of files but not 380, just wanted to point that out. Each individual file is actually rather small. There are only a few larger files in there (Vagrant::Environment actually perhaps being the only one).

"Why the codebase is at this size." Well, Vagrant started very small, but in the 3 years of its existence, it has gained a lot of what I've previously heard called as "code wisdom:"

* Generic host support since some tasks are host-specific. For example, setting up NFS on Mac OS X differs from Ubuntu which differs from FreeBSD. Vagrant knows this.

* Generic guest support. Setting up a variety of things is guest OS specific, so again, Vagrant knows how to configure networks, mount folders, etc. on a variety of different guest operating systems.

* VirtualBox bugs. Vagrant has quite a bit of code to work around VirtualBox bugs.

* Networking is hard. Vagrant does quite a lot with networking to ensure your networking works as expected. It also does things like port collision detection to verify that any ports you choose won't collide with any other VMs as well as making a best effort to check if that port is open, and erroring in that case as well.

* Plugin interface. Almost every part of Vagrant at this point in git master is customizable. This isn't overkill, this was built out of seeing actual human need for this. This lowers the number of features I need in core and actually fights being overkill, because more things can be built with plugins.

* Communication abstraction. Linux and POSIX-like guests with SSH is great, but what happens when you want to run Windows guests? SSH CAN work but isn't ideal. For this reason, Vagrant is started to abstract out communication so that Windows can use things like WinRM, completely transparently. Also, if you use something like VMWare, it uses the VMWare guest communication API, which is blazingly faster than SSH. Again, this is all transparent to plugin developers, provisioners, etc. It "just works."

It does much more, but I think you get the idea.

Building something that "just works" comes at a cost. And that cost is usually complexity. Can you build a very basic tool to control VirtualBox virtual machines in a small shell script? You betcha! Vagrant started this way. Can you make that reusable? Yeah, but prepare to add some complexity. Then make it run on every major OS and support some nifty features and you got yourself a big project.

I hope that helps!

The power in Vagrant is not the technology, it is actually the workflow. Vagrant is now in use by thousands of companies worldwide (some of the bigger ones you can see on vagrantup.com), and they consistently tell me that the power in Vagrant is that every developer, designer, etc now knows they can get some code and just type `vagrant up` and be working within a few minutes. When they're done? `vagrant destroy`. Small example, but Vagrant provides a consistent workflow.

There is a benefit to having this workflow on other systems.

First, VirtualBox has major problems. VirtualBox routinely kernel panics on a variety of operating systems, even leading to the point that there is a commit to the linux kernel that ignores crash reports from VirtualBox.

Second, the whole goal of Vagrant is to have development mimic production as closely as possible, and to make development fun. Some companies that use Vagrant can't mimic production very well on a single laptop, so they have a private cloud. They still want to use Vagrant -- because of the workflow! -- and this caters directly to them.

Also, for people on Linux, I know its not full virtualization, but some problems can be solved with simple LXC. Those people write scripts around LXC because LXC is pretty simple, but it would be pretty nice to get the benefits of Vagrant there, too. That is coming! Vagrant will support LXC.

Libvirt doesn't compare to Vagrant at all. If anything, they compliment each other.

And veewee-like functionality will make its way into Vagrant core very soon.

Vagrant author here.

This is incorrect. I am not trying to reimplement libvirt at all. If anything, I'm providing the infrastructure to use libvirt WITH Vagrant. Actually, surprise! I'm working with RedHat to do JUST THIS.

I applaud the libvirt project for everything they've done. We've had our difference, but I have no intention of competing with that project. The power in Vagrant is the workflow of Vagrant, not Vagrant's ability to abstract away the hypervisor (and I certainly don't want to play that game).

The power in Vagrant is the workflow, and that is the game that I'm playing.

It is worth searching through all these comments and reading what Mitchell (mitchellh) has to say. It's been very informative getting the author's perspective on every important issue brought up in this thread.