When using the salt provisioner with verbose=true, most lines read with an extra newline:
```
[INFO ] Syncing modules for environment 'base'
[INFO ] Loading cache from salt://_modules, for base)
```
because the line read has a newline, and emitting the log entry again includes an additional newline.
fixes#3083
Detect the presence of the default DHCP server that comes in a fresh
VirtualBox install and clean it up to prevent it from colliding with
Vagrant-managed network config.
In order to accomplish this, we:
- add a `remove_dhcp_server` call to the virtualbox driver
- fix dhcp options parsing to allow `:dhcp_{ip,lower,upper}`
configuration options to make it through (so a user can override the
removal behavior with some explicit configuration)
- add the full `:network_name` to the details returned from
`:read_dhcp_servers`, so we can have a durable value to pass to
`:remove_dhcp_server`
Note that we do have to eat one more `VBoxManage list dhcpservers` for
each network interface to support this, but this seemed like a nominal
cost
This is just a refactor, no behavior change.
Instead of stitching together dhcpserver info in the structure returned
from `read_host_only_interfaces`, sprout a new driver method called
`read_dhcp_servers` to return that information separately.
This means that driver clients (well there's really only _one_ client in
`ProviderVirtualBox::Action::Network`) have to do a bit more work to get
interface and DHCP server information.
But this gives us (a) a cleaner and more consistent driver interface and
(b) groundwork for a fix for #3083, which will require interacting with
DHCP servers outside of the context of host-only interfaces.
test-only change
when rsync is not installed on the machine running the unit tests, the
prepare_nfs_settings tests end up calling the :nfs_installed capability
on the host, which fails on the fake host wired up in tests.
this adds some explicit stubbing to prevent the implicit assumption that
rsync is installed.
This separates the truly basic pieces of Chef (like install url and
log_level) from the runner pieces of Chef (like provisioning_path). This
is necessary because the Chef Apply provisioner does not actually need
most of the Chef configuration options.
This is the result of an unhappy customer who raised a very valid point. If you
are not on the Vagrant mailing list, you would be unaware that upgrading VMware
would cause your plugin to stop functioning.
While this does not solve the problem of dispersing that information, it helps
clarify that plugin version support is for the latest version of the Vagrant
plugin and does not extend to previous ones.
Seth Vargo
Jeff Quast
Paul Hinze
Gilles Cornu
Felix C. Stegerman
Seth Vargo
Mitchell Hashimoto
Matt Wrock
Julien Vey
Alvaro Miranda
Vít Ondruch
Chris Jones