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.
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.
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.
This will eventually replace the Environment#vms method. Because of the
introduction of providers, the environment doesn't know what the backing
of the machines will be (and they're _machines_ now, not _vms_).
Instead, users of Environment will now call `#machine` on the
environment to retrieve a machine with the given backing provider as it
needs it.
This is done by calling the `upgrade` method on the _old_ configuration
classes. The old configuration classes are given the complete new
configuration and can set whatever settings they need to on it.
These are classes that use NO core classes of Vagrant, and are therefore
safe to load for upgrades. i.e. a V2 core can load a V1 config class
that is deemed upgrade safe without crashing Vagrant.
Before we were manually going over every plugin and getting each piece,
all over the place. Now we have a central manager that will give us all
the pieces we want. There is still some cleanup to do here but this is
much better overall.
The built-in middleware sequences will now be hardcoded onto
Vagrant::Action. Other plugins can hook into these sequences to provide
verification and so on. So the VirtualBox plugin will hook into that
action sequence and add verification.
This works by now calling the `:ssh` action on the provider. This action
is allowed to do whatever it pleases, but should at some point probably
call the `SSHExec` built-in middleware.
The `SSHExec` built-in middleware was added. This uses the information
returned by `Machine#ssh_info` and uses the `Vagrant::Util::SSH` helper
to exec into the remote machine. The provider should do any work upfront
in verifying that the machine is ready to be SSHed into.
This starts the transition of replacing VM with Machine. Machine still
isn't ready to fully replace VM but by moving it now, I'm able to find
the spots that need to be fixed. At this point `vagrant status` works
with the new provider interface.
This is the class that will represent a machine that is managed by
Vagrant. The class has a number of attributes associated with it and is
meant to be a single API for managing the machines.
In the case that not provider is given then whatever provider the box
represents will be added to the system. Ideally, a provider will be
given, but if not, Vagrant still does a "best effort" to install the
box.
This involved defaulting all box searching at the moment to VirtualBox.
Additionally, box upgrading is not yet handled. This needs to be done at
some point.
The box collection can now find new-style boxes with providers and
return proper Box objects. In the future, we'll also have to implement
upgrading old style ones as well.
This is the beginning of the new box internals. The basic idea is that
the new box has a new field: provider. The provider will describe what
provider that box was built with and what provider it is made to work
with.
The future of subclassing things like configuration bases and so on will
be to use `Vagrant.plugin(version, component)`. For example:
`Vagrant.plugin("1", :provisioner)`.
Before, the tempfile "f" could be GC'd before the path was used,
resulting in failed tests because when it is GC'd the tempfile is
removed. We now store the tempfile in an instance variable so that it
isn't even available for GC until after the test is finished running.
Mitchell Hashimoto
skim
Nate Smith