Vagrant core no longer tied to VirtualBox

Mitchell: First allow me to apologize for the tone of my comment. Re-reading it now, I realize that I glossed over a key point: I used Vagrant every day for a team of 5 people. In general, it worked very well, rarely broke in any way, saved us a whole bunch of time getting up and running. So thank you for your small, but real, contribution to my startup.

> middleware was so _painfully_ the RIGHT way to do things

I did see how you were composing the operations and I'm familiar with the middleware pattern; thanks for sharing your talk. However, I think this is one of those cases where OOP has a name for something that FP just takes for granted: function composition. Regardless, Clojure's Rack equivilant does provide middleware as functions of request -> response maps. It's much nicer to work with, but that might be a result of Clojure's design vs Ruby's and unrelated to Vagrant: https://github.com/ring-clojure/ring/wiki/Concepts

> Write a shell script that does the following

I don't have any of those requirements. I only need to support OSX as the host OS. The team's MacBook Airs don't have enough resources to run more than one VM, so I don't ever worry about port collisions. I need to configure my network adapters anyway for my production deployment, so I just need an if statement or two in that config file template. Hell, I don't even need the ability to turn off a VM gracefully, since kill -9 seemed like a decent way to test crash recovery.

Even thought I don't have those requirements: I used Vagrant. It saved me some time up front.

But that complexity has a cost. Running `vagrant ssh`, for example, took 3ish seconds on my machine. Again, this is probably due to RubyGems, which is painfully slow. I had to explain to the team to run `vagrant ssh-config >> ~/.ssh/config`, then to go tweak that a bit, so that they could write `ssh dev` and have it be instantaneous.

Worth noting however, is that I already needed a way to generate local ssh config for each production box to be able to talk to specific other production boxes, and for client machines to talk to our cluster. Vagrant's ssh-config command was just one more extra moving part to concern myself with, so I manually put the correct config into a cat script along with the production needs, and added it to the build process.

There was one or two more of these little things that escape my memory now.

> make all of that REUSABLE and EXTENSIBLE

I think my main complaint about Vagrant is one which you seem to be fixing, starting with the very commit that this HN thread is attached to: You're pulling out the REUSABLE bit of abstracting away various virtualization platforms across a variety of host and guest operating systems.

However, I'm a big believer that EXTENSIBLE does not belong in library code. Extensibility belongs at user layers. Furthermore, extensibility is really fucking hard. 99% of the time, I'd rather the core be more reusable and allow me to bypass extensibility.

I think that Git is a perfect example of this design. They call it plumbing and porcelain. The plumbing commands offer zero extensibility. They don't have any creature comforts, as their output is tuned for parsing. The goal of these commands is to manipulate the abstractions of the underlying system. The porcelain, by contrast, does offer extensibility via git-foo.sh scripts on your path, aliases and configuration, commit hooks, etc. I'd see a lot of value in something like this for virtual machine management.

Another example would be Chef & Puppet's facts systems. I forgot what they are called. Ohai? Something like that. They provide OS-independent interfaces for gathering facts about machines. Those components should be hoisted to first class project status!

Unfortunately, Vagrant does not, yet, provide a plumbing vs porcelain split. In many ways, I view Vagrant like SVN: It's a damn solid piece of software. Lot's of people get a ton of milage out of it. However, it's underlying concepts are slightly muddled together and there are huge gains to be reaped from deep thought and careful modularization. When those big gains do come, they will only work on a single platform, maybe one or two guest operating systems, people will bitch about it's low ease of use, despite it's inherent simplicity, but the people who deeply understand machine provisioning and management will adopt it in droves, until eventually Windows support doesn't suck too bad, all the various use cases are more or less covered, and people are wondering "How can you possibly still use that old thing?"

I think you've got a good start towards that goal in Vagrant, but my complexity sense is tingling.

> I'd say Vagrant's 3000 line of code count is pretty spot on

I just ran cloc on the master branch locally; I see 12355 lines of Ruby ;-)

The integration with Chef is enough for any engineer using Chef to configure and deploy their software to choose Vagrant over any other solution.

The Chef community has had major success in automated testing of their Cookbooks (units of configuration in Chef) and it is all made possible by Vagrant.

"However, I think this is one of those cases where OOP has a name for something that FP just takes for granted: function composition. Regardless, Clojure's Rack equivilant does provide middleware as functions of request -> response maps."

I'd like to address some of the finer points in the comparison of middleware vs function composition that have been overlooked.

First class functions - While Ruby does indeed have lambda's and blocks it does not have first class functions, or partial application. This makes state and argument management much more difficult. That is, Vagrant would have to cram _everything_ into `env`...

State - The middleware(s) operate on a common state container `env` and this is where the initial composition comparison arises. The common argument is consistently the `env`. The problem with cramming everything into `env` is that you discard data encapsulation. All the things are known to all the people, which is unnecessary and can cause implicit dependencies between middleware(s). By instantiating a class with values specific to its operation we avoid this issue all together. To achieve a similar result with pure functions you would need something like partial application which Ruby simply doesn't support. It's also worth noting that with pure functions you could adopt a monadic pattern for composing and managing the state which is, IMO, a more accurate analog [1].

Method dependencies - With regular functions you have two choices, you can simply use a global reference to a helper function to maintain discrete testable operations or inline all the different bits of functionality into the function itself thereby making it difficult to test. Generally speaking I'm a fan of keeping those helpers namespaced and easily sharing the small bits a state specific to the instance's operation between them via context. Keep in mind that small classes with sparse state access through the implicit self can actually be more readable, and the ability of the reader to reason about execution isn't hindered too horribly by the implicit state.

Warden - Implementing a recovery pattern is hard using just pure functions. In Vagrant a watcher middleware (Warden) is inserted between each middleware to catch exceptions. When an exception is thrown, because the parent is the Warden it can then recognize its place in the stack and work backwards calling a `recover` method on all the preceding middleware in the stack. This means that each middleware is effectively two methods. One for the initial operation and a second for recovering in the case of failure. You can implement something _similar_ using Either, but in reality you need a custom record data type that carries both functions in which case you're not composing a simple function any more and the difference is really just that Vagrant is written in Ruby. I've written a blog post on the inspiration for Vagrant's Warden implementation if you're interested [2].

Vagrant's Middleware != Rack - PEP333 makes no assertions about state cleanup because in an http request there really isn't much state (the prescription is to return a helpful error message[3]). Vagrant on the other hand is writing hundreds of MB to the disk and needs to clean up when something goes wrong, so I'm not sure that drawing a comparison with a Rack implementation makes sense.

1. http://johnbender.us/2010/07/22/middleware-composition-and-m...

2. http://johnbender.us/2010/10/18/haskell-and-vagrants-middlew...

3. http://www.python.org/dev/peps/pep-0333/#error-handling

Ubuntu's business server is hardly something as turn-key as vagrant.

We use Ubuntu on EC2 and Canonical has made so many atrocious decisions since the release of 10.04, I am not sure if I ever want to run anything from them again. =( We are however heavily invested with custom PPAs and all that.

Back to Vagrant - as others said before: `vagrant up` and productivity starts. At work I manage local and remote people and they all work with Vagrant. It works the same for developers and frontend people. And most importantly: it works.

Yes, there are ins and outs, but they are mostly Virtualbox related and I cannot wait until other virtualization is supported.

Forgive me for derailing the conversation, but I've been following this thread about the Cathedral & The Bazzar: http://news.ycombinator.com/item?id=4407188

In particular, I've found the discussion of autoconf to be fascinating. I think what fundamentally bothers me about Vagrant is that it feels like autoconf. By that, I mean it's a system which 1) hides a ton of hard work that users don't need to do to target multiple backends 2) accomplishes that hiding through complexity 3) further hides that complexity through an "easy" interface 4) generally just fucking works most of the time 5) is completely maddening to deal with when it does break 6) ideally shouldn't need to exist.

Anyway, I realize that ideals != reality. I also realize that I've got a learned behavior of reinventing the minimal viable tool from fundamentals to avoid dealing with the complexity of problems that I don't have. And furthermore, I realize that my learned behavior is of limited applicability outside of narrow environments, such as my own startup where I own the full stack and make all the rules.