Temporary limitation of Vagrant to only allow one active machine with a
provider at a time. That means you cant `up` a machine with both vmware
and virtualbox at the same time. In the future you will be able to but
to avoid various edge cases for now we're disallowing it.
See the code and comments for details on how this is done. As usual, we
are very careful about this so as not to inadvertently destruct real
user data.
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