When the provider supports parallel actions and actions are being
run in parallel, do not immediately kill the process on failure.
Instead terminate the action thread and log the exit code. Once
all running actions have completed, the process will then exit
with the stored exit code.
Prior to this commit, the docker compose driver would _always_ path
expand a host volume no matter what. This is not always the correct
option, for example if that host volume is actually a reference to a key
inside a `volumes` hash instead of a path on disk. This commit changes
that by looking to see if the requested host volume is actually a
defined key inside the compose config, and if not, it will path expand
it like before. Otherwise it will leave the key "as is".
Use `mask` option for defining subnet on network configuration. Allow
options to be passed through using hash scoping and docker_network and
docker_connect prefixes. Enable public networks. Allow configuration
to define pre-existing networks by name.
This commit updates the behavior of how the docker provider creates new
docker networks. It looks at each existing network to see if the
requested subnet has already been configured in the docker engine. If
so, Vagrant will use that network rather than creating a new one. This
includes networks not created by Vagrant. Vagrant will not clean up
these networks if created outside of Vagrant.
Prior to this commit, if a box some how got on disk that had an
incorrect or invalid version number that did not match Gem::Version,
Vagrant would throw an exception when attempting to generate a list of
the boxes on disk. This commit fixes that by looking at the version from
the path generated, and shows a warning to the user about the box and
skips it from the list so they at least know about the problematic box
and can still get a list of boxes.
This commit introduces some basic functionality for typed triggers:
- command
- action
Command triggers are triggers that will run before or after a given
sub-command.
Action triggers are for running triggers before or after internal
actions for Vagrant. This could be before or after a provision step,
before or after synced folders, or networking, etc.
Prior to this commit, Vagrants output would only show that a file
provisioner was running, but had no detail as to what file was being
copied to where. This is especially confusing if a Vagrantfile has
multiple file provisioners. This commit updates that by showing the
source and destination of the file so that it's clearer what is being
copied and to where.
This PR adds support for running command passed via the --command
flag as elevated tasks. The option is only valid for commands and
not when setting up a remote session. Logic has also been adjusted
for when communicator restrictions are applied and test coverage
has been added.
Rescue and re-wrap any errors encountered when running the post
rsync capability. Rescue this exception type and notify of error
when encountered by rsync auto. Include test coverage.
Include config option within ssh_config command output template. Default
remote_user value to set username value. Include existence check on
provided config value to ensure file is available. Update tests to
include coverage on all changes. Add new options to the docs.
This commit introduces a special flag for enabling features that are not
ready for release. It can either be enabled by setting the
`VAGRANT_EXPERIMENTAL` flag to "1", or by setting it to a string of one
or more comma seperated values for specific features. It also adds a
couple of Vagrant developer focused methods for making it easier to
determine if the flag has been enabled, and if so, what features.
Prior to this commit, if you specified a `version` for the salt provider
but no `install_type` Vagrant would fail to pass the proper parameters
to the bootstrap install script. This commit fixes that by adding some
validation to the salt provider if `version` is specified but not
`install_type`. It also adds some extra context for certain config
validation error messages so that the user knows what option was
incorrect, rather than the message just referring to the option as
*this*.
Prior to this commit, Vagrant would attempt to path expand a file that
didn't exist if it was left out of the passed in arguments and no
`--url` was used for external box uploading. This commit fixes that by
adding some additional validation for the passed in box file.
In some cases the E1000 NIC type is the only acceptable value. Since
defaulting causes breakages to existing boxes, leave the default value
as `nil` but check the VirtualBox version in use and print warning to
user if VirtualBox version is vulnerable and E1000 NIC types are
configured for use within defined network adapters.
This commit adds a new flag to the `vagrant validate` command which
allows users to completely ignore the provider block of a config file.
This is useful for when you are running `vagrant validate` in CI and
don't want to install a valid provider to check the syntax of your
Vagratnfile. When the flag is invoked, a warning will be displayed
saying that the provider block will be ignored and not validated.
This commit introduces a new uploader class for uploading files and
splits up some commonly used functionality between it and the downloader
class into a curl helper library.
This commit introduces a new option to the core trigger feature: `ruby`.
It can be defined to run ruby code when the trigger is configured to
fire. If you give the ruby block an env and machine argument, the
defined ruby code can use those variables internally.
Dynamically generate RDP information when applicable via provider
if supported. When no RDP port is provided ignore RDP in config
and omit from output.
This commit adds a new option `abort`, which when configured, will exit
the Vagrant process completely. If set to `true`, it will exit cleanly
with exit code 0. Otherwise, the exit code can be configured.
Reloading the Vagrantfile causes issue with multiple evaluations
where users expect single evaluation. Instead of allowing local
plugin installation to happen prior to command execution, force
halt after installation and the command to be re-run. This will
prevent multiple loads of the Vagrantfile within a single run.
Prior to this commit, the run trigger option wouldn't catch for failures
outside of the #Subprocess.execute raising exceptions. This commit fixes
that by inspecting the exit code result of the subprocess and using the
new `exit_codes` option to determine how to move forward with the
trigger.
Prior to this commit, vagrant would halt if it could not parse the
metadata file for a box to check for updates with. This commit changes
that to behave like when vagrant fails to download a metadata file and
continue on but warn the user it failed to check for box updates.
This commit adds a bit more helpful messaging for the user when asking
for a provider that might not exist or does not follow the correct
casing. If it can find a match on a provider it knows about, it will
suggest it.
This commit adds a function on windows for the VirtualBox provider to
check if Hyper-V is enabled. If so, exit and display a warning to the
user that going forward will result in a system crash.
Display warning to user about the VirtualBox SharedFoldersEnableSymlinksCreate
option with link to VirtualBox documentation and instructions on how the
setting can be disabled.
Prior to this commit, when the `--global` flag was used with the
`vagrant box outdated` command, it would ignore box providers and not
inform the user of all outdated boxes. This commit fixes that by
displaying each box within the users environment, and includes the
provider of the box in the message.
As of `net-ssh` version 4.2.0, the key :paranoid has been deprecated in
favor of using :verify_host_key. This commit updates Vagrants ssh config
to use the new key, and deprecates the use of :paranoid.
This commit adds some additional handling for when Vagrant loads config
files. Instead of showing the basic ruby exception, it prints a more
helpful error message and tries to direct the user to the line number
and file where the exception is occuring.
This commit adds better messaging to the user if the parallel flag is
used without the force flag. It also makes the state checking based on
the delta between the initial and final states of the guests due to the
fact that there is no guarantee what the "destroyed" state id will be
between providers.
- Keep the Programming Errors with corresponding Exception class and
en.yml message template. Fix the alphabetical order in errors.rb by
the way.
- Fix English wording in the documentation and en.yml messages
- Use StandardError for unknown error rescuing.
Thanks @chrisroberts!
Vagrant will verify that the current Ansible version does support the
requested compatibility mode (only applicable if not "auto", of course).
As mentioned in the documentation, there is no sanity checks between
`version` option and `compatibility_mode` option.
With this change, the host-based provisioner is also improved to
execute only once the "ansible" command (and store the gathered
information for multiple usages like version requirement and
compatibility checks). On the other hand, the guest-based provisioner
can still potentially execute "ansible" twice (once in the
AnsibleInstalled cap, and via "gather_ansible_version" function via
Base::set_compatibility_mode).
Before this change, only the ansible_local provisioner supported this
option (for ansible version requirement, and pip installation). Now, the
ansible host-based provisioner can also require a exact ansible version.
Resolve#8914
Note: this has been added as part of #6570 resolution, since the
introduction of the `compatibility_mode` auto-detection made both
provisioners made capable to detect ansible version.
Pending: optimize the code to avoid duplicated executions of "ansible
--version" command.
With this change, it is now possible to get rid of many deprecation
messages successively introduced in Ansible 1.9, and 2.0. More
interesting, the generated inventory will contain the recommended
variable names (e.g. `ansible_host` instead of `ansible_ssh_host`)
when the compatibility mode is set to '2.0'.
Details:
- Add `compatibility_mode` option to control the Ansible parameters
format to be used. The value corresponds to the minimal version
supported. For the moment, possible values are '1.8' (corresponding to
Vagrant's former behaviour) or '2.0'.
Note that a dynamic inventory generated in compatibility mode '2.0'
is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far
supports inventory format generated by the compatibility mode '1.8'.
- Add compatibility mode auto-detection, based on the available Ansible
version. This is the default behaviour in order to bring a maximum of
user friendliness. The drawback of this approach is to let potential
compatibility breaking risks, for `ansible` provisioner setups that
already integrate Ansible 2.x **AND** rely on the existence of
the generated `_ssh` variable names. Thanks to the vagrant warnings
(and its release notes), I argue that it is worth to offer
auto-detection by default, which offers a sweet transition to most
users.
- Add `become`, `become_user` and `ask_become_pass` options and their
backwards compatible aliases. The legacy options are now deprecated.
Note that we intentionally didn't provide a '1.9' compatibility mode,
as it would add extra-complexity for practically no added-value.
To my knowledge, the Ansible 2.x series haven't introduced yet any major
changes or deprecations that would motivate to introduce a higher
version compatibility mode (to be confirmed/verified).
Resolve GH-6570
Still Pending:
- Optimization: Reduce the number of `ansible` command executions.
Currently two exec calls will be performed when the compatibility
mode auto-detection is enabled (i.e. by default). We could make the
provisioner a little bit smarter to only execute `ansible` only once
in any situation (by combining "presence" and "version" checks).
- User-friendliness: Add better validator on `compatibility_mode`
option, and shows a warning or an error instead of the silent
fallback on the auto-detection modus.
- Test coverage: All the added behaviours are not fully covered yet.
Prior to this commit, if you set up multiple folders to export with NFS
on linux with the exact same hostpath, the template used to write
/etc/exports would end up placing the same path with the same IP in
/etc/exports and cause an error preventing the folders from being
properly mounted. This commit fixes that by first looking at which
folders are being exported and if there are any duplicates. If so,
remove the duplicates and only export 1 hostpath folder. If these
duplicate folders have differing nfs linux options, an exception must be
thrown because we cannot assume which options the user intended to
export with.
This commit introduces the salt_arg option that allows a user to pass
additional command line flags to the `salt` tool when provisioning with
a master setup.
It also adds additional config validation to ensure that both
`salt_args` and `salt_call_args` is an array.
Adds powershell validation to ensure powershell is available on
the PATH and checks powershell version to ensure meets the
defined minimum powershell version.
Prior to this commit, when users invoked the `rsync-auto` command using
the docker provider with boot2docker, vagrant would rsync all known
containers using the boot2docker vm rather than the current working dir.
This commit updates that behavior to ensure that only the current
working dirs vagrant machines will be rsynced.
* ALT Linux platforms is an original rpm based distribution
forked as Mandrake Russian Edition Spring at 2001 year
* Distributions of ALT Linux use etcnet (https://www.altlinux.org/Etcnet) as
internal network configuration system needs for configure_networks support
Prior to this commit, if a user attempted to configure
`/etc/default/docker` through vagrant prior to installation, the package
manager would not override an existing configuration and installing
docker would then fail. This commit fixes this by introducing a
`post_install_provisioner` that allows users to define a provisioner
block that will run after docker has been installed, allowing users to
configure `/etc/default/docker` how they want.
This commit adds some better handling around the snapshot restore and
delete commands for the virtualbox provider. If a user attempts to restore from
a vm that does not exist, instead of exiting 0 it will raise an
exception saying the virtual machine has not been created yet.
Addtionally, if a user attempts to restore from a snapshot id that does
not exist, instead of printing a complicated exception from the
virtualbox cli tool, it prints a more useful error message telling the
user that the snapshot does not exist.
Whenever the path where the machine was first created changes, Vagrant
will now show just one warning when an action is run on the machine.
The idea is that if a user copies the machine over to a different
directory with the idea of running two different machines, this warning
will now help the user determine how to make that work.
Prior to this commit, if a user set a URL for the name of a box, vagrant
would not warn the user about using box_url instead. This would lead to
some difficult user experiences around the various box commands due to
the box name being a full URL. This commit introduces a warning to the
user and lets them know to instead use box_url.
Prior to this commit, if a user attempted to use the `vagrant snapshot
save` or `vagrant snapshot list` commands on a vm whose provider did not
support snapshots, it would simply print a warning. This commit changes
that behavior by instead raising an error.
Prior to this commit, the vagrant snapshot plugin would save snapshots
with existing names which lead to duplicate snapshot names being saved.
This commit fixes that by checking to see if the given snapshot name
already exists and if so, fails telling the user the given snapshot name
already exists. If a user passes a --force flag, vagrant will first
delete the existing snapshot, and take a new one with the given name.
Enables proper setup of VMs started from within WSL rootfs paths. Updates
setup for Windows access when working within the WSL to auto-detect settings
instead of relying on user defined environment variables.
This makes the behavior of the docker and hyperv provider consistent with the
virtualbox provider by raising an error on ssh actions if the machine is not
created or not running.
Fixes#8508
Properly detects NetworkManager on guest as well as devices controlled
by NetworkManager. Provides configuration option to enable/disbale
NetworkManager control on devices.
In some cases the SSH connection may be aborted while waiting
for setup. This includes aborted connections in the list of
applicable exceptions to retry on while waiting for the connection
to become available.
Fixes#8520
Allows checksum validation on downloaded files via Util::Downloader
using MD5 and/or SHA1 checksums. This also integrates checksum validation
support with the shell provisioner for downloaded remote files.
The `pkg_add` command will return `0` when a package requested for
installation is not found. This adds a validation check to ensure
the rsync package is actually installed on the guest.
BSD-based guests do not support VirtualBox shared folders. This is a
common source of confusion in Vagrant. This new error clearly explains
that this is not a bug in Vagrant and provides instructions on how to
disable them.
