Now we have different providers, but the error message didn't tell
anything about it. Suppose I want to remove one of my boxes:
vagrant box remove opscode-ubuntu-12.04 vritualbox
There is a typo in provider name. The error message is:
Box 'opscode-ubuntu-12.04' could not be found.
Therefore I need to double check the box name, and only than I will see
the typo.
This commit make the error message looks like this:
Box 'opscode-ubuntu-12.04' with 'vritualbox' provider could not be
found.
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 branch brings in the "machine abstraction" code. This is a major
milestone in the development of Vagrant as it abstracts all of the
VirtualBox-specific code out into a plugin. There is zero VirtualBox
specific code in the core ("lib/") directory at this point. Read on for
important points.
== Gotchas
White it is technically possible now to write plugins for other
providers, there is still major work to be done to make this feasible.
The plugin interface itself is pretty much done, but there are some
issues:
* ":virtualbox" is the hardcoded provider to be used at the moment.
* There is no way to configure a provider. For example,
`config.vm.customize` would never work for anything other than
VirtualBox, so there needs to be a way to have provider-specific
configuration. This will come soon.
* Shared folders and networking need to be rearchitected to be friendly
for multiple providers, since it is unrealistic that a provider such as
EC2 could provide the same level of networking, for example.
* There is no way easy way (like `vagrant package --base`) to create
boxes for providers other than VirtualBox. This will be addressed in a
whole new feature of Vagrant probably in a future release after
provider stuff has shipped.
== Writing a Provider
To write a provider, you create a Vagrant plugin that defines a
"provider". See the "plugins/providers/virtualbox/plugin.rb" for more
details. Providers themselves have an exremely simple API. The burden
for writing providers mostly rests on the fact that you must define
complex middleware sequences.
Lots more work to come in the future, but this is a BIG MILESTONE!
`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 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.
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!
Anton Kalyaev
Mitchell Hashimoto
Hugues Malphettes
Paul McKellar