Commit Graph

127 Commits

Author SHA1 Message Date
Mitchell Hashimoto 81ca275792 Providers to V2 2012-11-06 21:20:55 -08:00
Mitchell Hashimoto 3c0341b7be Disable DNS proxy for 12.10 too 2012-10-12 20:03:25 -07:00
Paul Visscher f36ab8a165 Fixes a bug with DNS resolution in Ubuntu 12.10. 2012-10-08 22:12:41 -04:00
Mitchell Hashimoto 678c6a070d VirtualBox 4.2 support 2012-09-13 19:11:32 -07:00
Mitchell Hashimoto 391dc39267 Merge branch 'machine-abstraction'
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!
2012-08-19 19:27:09 -07:00
Mitchell Hashimoto 85a4fb82a8 `vagrant package` a single VM works! 2012-08-15 21:04:37 -07:00
Mitchell Hashimoto b659191a02 `vagrant up`! 2012-08-14 22:38:41 -07:00
Mitchell Hashimoto aaeb060f33 `vagrant provision` 2012-08-14 21:21:31 -07:00
Mitchell Hashimoto 7aa083d259 `vagrant reload` now works with the new machine abstraction 2012-08-14 21:12:41 -07:00
Mitchell Hashimoto 85a499ffb8 Properly handle the case that VM doesn't exist for the VB driver. 2012-08-14 20:27:28 -07:00
Mitchell Hashimoto 0cc63c05e2 `vagrant destroy` fully works 2012-08-13 23:31:12 -07:00
Mitchell Hashimoto 2fc18f7207 `destroy` gets a little farther, and properly halts the VM 2012-08-13 23:18:50 -07:00
Mitchell Hashimoto bca8663742 `vagrant resume` works with the new machine abstraction 2012-08-13 20:03:35 -07:00
Mitchell Hashimoto 83b908f3d8 `vagrant suspend` works with new machine abstraction 2012-08-13 19:30:41 -07:00
Mitchell Hashimoto 0eddda3552 Halt works with new machine.
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`.
2012-08-12 18:54:52 -07:00
Mitchell Hashimoto f9752d78d8 Properly resolve and load the guest class impl for Machines 2012-08-12 18:35:19 -07:00
Mitchell Hashimoto 5e70ad0ec2 `vagrant ssh -c` now uses a middleware sequence 2012-08-10 00:57:23 -07:00
Mitchell Hashimoto e0ec679838 `vagrant ssh` with full console works with new provider.
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.
2012-08-05 13:45:24 -07:00
Mitchell Hashimoto 9db982f7a4 Expose the provider via the machine object. 2012-08-04 11:16:31 -07:00
Mitchell Hashimoto 1e997f87d7 Clean up the actions a bit, move logic into actual middleware.
This is a good idea because in the future it will allow plugins to
properly override these behaviors.
2012-07-28 19:58:10 -07:00
Mitchell Hashimoto 31a3a3f2e2 Start moving the halt commands over to the new provider interface 2012-07-28 10:43:16 -07:00
Mitchell Hashimoto e5f250121a Call now only yields the environment 2012-07-27 19:34:46 -07:00
Mitchell Hashimoto 118377e6f0 Destroy sequence asks the user for confirmation. 2012-07-27 19:29:40 -07:00
Mitchell Hashimoto 90517a0f9b The `Call` built-in middleware allows for conditional MW sequences.
Read the documentation for more information.
2012-07-26 23:56:47 -07:00
Mitchell Hashimoto 5eed3b8417 Building up the `destroy` action again using new provider API.
This shows me moving the built-in middleware sequences to the provider
and how I'm organizing all that.
2012-07-26 22:39:27 -07:00
Mitchell Hashimoto 44b4b9dfef Move drivers to the VirtualBox plugin. Use Machine class.
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.
2012-07-24 21:32:38 -07:00
Mitchell Hashimoto 3519bf0372 Add the "provider" API to the V1 plugin. 2012-07-15 11:17:58 -07:00