`vagrant package --base` is deprecated for a future feature so I didn't
want to waste any brain cycles on how to do this the "right" way since a
new system will be introduced to do this sort of thing in teh future.
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 required some modifications to the linux guest implementation. And
the other guests will have to be modified as well. This is because
`channel` is now `communicate`.
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.
On Debian systems config.hostname directive should change /etc/mailname
in order to prevent problems with default mailer trying to contact
default vm's name.
* Renamed the run_puppet_client method in the puppet provisioner
to clarify it's function running Puppet in apply mode from the
command line.
* Renamed the run_puppet_client method in the puppet server provisioner
to clarify the agent is being run.
* Changed the Puppet server provisioner to use the more standard Git-style
command line structure. The puppetd binary has been deprecated in favour of
puppet with the agent flag.
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.
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.
I don't use `activated` here because I'd really like to optimize
performance as much as possible, and loading files from disk is
generally slow. So instead of using `activated` I load the file at the
last possible moment which is when the exact class is being requested.
I don't think many people will do this outside of the core, and I'm not
too concerned.
Easy commands are well... easy! They don't offer the full power of
creating a completely custom command class, but they let you do the
basics (what almost everyone needs) with minimal fuss. Example:
class MyPlugin < Vagrant.plugin("1")
name "my-plugin"
easy_command "foo" do |action|
puts "HELLO!"
end
end
NOTE: The "action" stuff isn't done yet, but will be soon!
Mitchell Hashimoto
jtimberman
Bob Maerten
James Turnbull
Jens Braeuer
Marco Monteiro
Benedikt Böhm