This branch changes how local data is stored for Vagrant environments
from a single "dotfile" approach to having a directory of data, more
similar in style to git.
When a V1-style dotfile is encountered, it is automatically upgraded
to the new style directory format.
Instead of storing an "active" hash in the local_data of an Environment,
we now place the ID of a machine in the "id" file of the machine data
directory. This file is read upon re-instantiation in order to load the
proper state.
The local data path is set to the `ROOT_DIR/.vagrant` by default and is
a directory where Vagrant can store environment-local state. This can be
overriden on a per-Environment basis using the `local_data_path`
option.
This branch brings in a whole lot of awesome. The name does not do it
justice. The list of things that comes into play here:
* "virtualbox" is no longer hardcoded anywhere in core. It is the default
provider, yes, but it is 100% possible now to slip in another provider
and have it work.
* `vagrant up --provider` is a thing. This allows you to specify an
alternate provider. Note that the other commands don't support
`--provider` yet so its not THAT useful, but its getting really close.
* True V2 configuration is in place. That means that `Vagrant.configure`
calls now are loading a completely new configuration version, and old
1.0.x Vagrantfiles are V1 configuration. V1 configuration is upgraded
automatically internally, so backwards compatibility is maintained.
Magic, people, magic.
* `config.vm.provider` is the major new configuration option. This is
how provider-specific configuration will be done. For example, Vagrant
has always provided a way to make a pass of `VBoxManage` calls to
customize your VM via `config.vm.customize` in V1. This now exists
as a VirtualBox configuration option. See the example here:
https://gist.github.com/98f5a0df6a05286dfb73
* Unit tests no longer depend on VirtualBox being installed, because for
unit tests we slip in a "no-op" provider, which is a fully valid
Vagrant provider plug-in that does... NOTHING! Brilliant!
* Lots of core middleware executor improvements that make writing and
using middleware stacks a lot more enjoyable. Enjoy a set of "standard
library middlewares" provided by Vagrant in Vagrant::Action::Builtin.
The multi-provider is really shaping up here.
The issue here is that when a middleware failed and a recovery sequence
started, it would halt at the "call" step because the "Call" didn't
properly recover the child sequence.
An additional issue was that a Warden had no "recover" method, meaning
embedded Wardens wouldn't recover their stacks properly.
This works by registering a `config` with `:provider => true` with the
same name as your provider. Vagrant will then automatically configure
the provider when `config.vm.provider` is used.
Boxes are provider-specific, and we don't know the provider until
Environment#machine is called, so we need to build up the machine
configuration during this time.
Mitchell Hashimoto