This can be removed since in the future all actions will come from the
providers or something. There are still issues with box actions but
we'll get back to that later...
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.
This error was experienced by @pearkes. It is thrown when the remote end
unexpectedly closes the remote end. This is usually caused by SSH not
being able to properly setup the connection.
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)`.
The basic process for this is to:
1. Load the configuration using the proper loader for that version. i.e.
if you're loading V1 config, then use the V1 loader.
2. If we just loaded a version that isn't current (imagine we're
currently at V3), then we need to upgrade that config. So we first
ask the V2 loader to upgrade the V1 config to V2, then we ask the V3
loader to upgrade the V2 config to V3. We keep track of warnings and
errors throughout this process.
3. Finally, we have a current config, so we merge it into the in-process
configuration that is being loaded.
This moves out the concept of a "default VM" from the Environment class
and makes it the responsibility of the V1 configuration that at least
one VM is defined on it. This lets the configuration ultimately decide
what a "default" implementation is.
This is useful so that it can take a look at the final loaded
configuration object and possibly make some tweaks to the configuration
object. The use case this was built for was so that config V1 can verify
that there is always at least a single VM defined as a sub-VM, the
"default" VM.
Previously, all procs were assumed to just be the current version. This
is certainly not going to be true always so now the version number of
the configuration must be explicit if you're assigning a proc to the
configuration loader.
This means that the Config::Loader now only knows how to load
configuration for versions used to initialize the class. This lets
things like the tests be completely isolated from what the actual
configuration is for Vagrant. This will be immensely useful to verify
that the loader functionality works for non-trivial bits (like
upgrading) without depending on Vagrant's upgrading functionality.
Since we're not calling this lambda from inside a method, the `return`
causes a LocalJumpError on 1.8.x. It appears this functionality works
fine on 1.9.x but we'd like to support both. The correct behavior
appears to use `next`.
I wanted to define my dotfile as: `config.vagrant.dotfile_name =
"~/.vagrant-projectname"` and noticed that the full path wasn't
expanded as expected.
This patch allows the vagrant file to be placed anywhere on the
filesystem.
There was an issue before where the stdin buffer would always have space
so it would always yield that block and Ruby would spin at 100%. Now we
require all callers to say what they want to listen for. This drops
CPU down to almost nothing.
See GH-832
Easy commands can now easily get arguments from the command line.
Using `arg`, you can get named arguments on the command line, such as
"--foo" or "-f"
With `arg_extra`, you can get any remaining arguments after a "--"
on the command line, which is a common pattern used to grab longer
parameters.
Some new APIs were added to the easy command operations. `info`,
`error`, and `success` are simple ways to output messages to the UI
without resorting to "puts" in Ruby, since the Vagrant UI object is the
idiomatic way to do communication with the world.
Additionally, `argv` was added which gives commands access to the
command-line arguments that are remaining that does not include the
vagrant binary or subcommand.
Also, behavior was changed: Previously, easy commands would run for
every target VM. Now, it is only run once with the primary VM. In the
next commit, I plan on adding a new flag that signifies an easy command
is meant to work with a named VM.
This change makes it so that SSH errors are shown, whereas QUIET hid
those as well. The main change to QUIET was to get rid of warnings,
not errors, so this fixes that.
Before, it only contained the shell executable and "-l" was magically
appended to it. However, every shell doesn't support "-l" and maybe "-l"
isn't even the behavior that users want!
Therefore, the config.ssh.shell command must now contain the full
command to execute.
Vagrant is only guaranteeing that the plugin definition superclass (the
Vagrant.plugin("1") part) is backwards compatible. Anything else, such
as Vagrant::Command::Base and so on, will likely change in future
versions. Beacuse of this, plugins should only immediately expose their
definition.
In order to support loading the other classes, plugins should defer
loading to the "activation" phase of a plugin. This can be done using
the `activated` block:
class MyPlugin < Vagrant.plugin("1")
name "my plugin"
activated do
require "myplugin/my_command"
end
command("foo") { MyCommand }
end
Plugin activation is done at two specific times:
* Right when a Vagrant::Environment is created and the global plugins
(such as from ~.vagrantrc) are loaded.
* Right before loading configuration, but after the Vagrantfiles have
been evaluated. This allows plugins to be defined within these files
as well.
Vagrant.configure is now how configuration is done in Vagrantfiles
(previously it was Vagrant::Config.run). This function takes a single
argument which is the version of configuration to use.
Various internals were updated for this new versioned configuration.
Note that multiple versions of configuration aren't yet used so aren't
fully supported by Vagrant, but the foundation is being set here.
I created VersionBase which is the abstract base class for any
configuration versions. Configuration versions are responsible for
knowing how to load configuration given a proc (from a
Vagrant.configure block), as well as merging configuration procs. In the
future, it will have to upgrade versions as well. This is not done yet.
The VERSIONS constant was added to Vagrant::Config which is a registry
to keep track of all the available configuration versions. The
VERSIONS_ORDER constant is an array of the ordering of these versions.
The ordering is important so that in the future Vagrant can attempt to
gracefully upgrade the configurations. It is also used to determine the
current configuration version (which is assumed to be the last version
in the order).
The loader was modified to use the current version and the VERSIONS
registry instead of hardcoding V1.
Mitchell Hashimoto
Mark LaPerriere
Paul Morton
Matt Robenolt
mxtthias
Zsolt Takács
Matt Callaway
Josh Mahowald
Mitchell Hashimoto
Ryan LeCompte