Output format of ui.info method (bold text) makes reading long script outputs really heavy on the eyes. ui.detail is a better match for this type of output.
Reverting the changes done in 7d2f7dab97
because they don't work and or update vagrant to invoke running the
vbox cli tool for every single forwarded port instead of forwarding them
all in one command.
Issue: https://github.com/mitchellh/vagrant/issues/8468
A lot of vboxmanage commands are flakey and frequently cause
bringing multiple machines up at once to fail, especially when
the host system is under heavy load. Most commands are also safe
to retry and just result in a no-op, so we can simply add
'retryable' to a lot of existing calls. For the others we need to
do a little bit of cleanup or reevaluate the parameters before
trying again.
- 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.
The patterns "all" is a special keyword that target all hosts in the
inventory. Therefore it makes sense to accept "all:vars" as a group
variable name. Note that "*:vars" pattern is not valid in an Ansible
inventory.
See http://docs.ansible.com/ansible/latest/intro_patterns.html#patternsFix#7730
This commit aligns how the file provisioner should work on all host
machines. It ensures that a `/.` is only applied if the user intended
to upload a folder to a destination under a different name. It ensures
that if uploading to a windows guest with a different destination folder
name, it does not nest the source folder under that name so that it
works the same as it does on linux platforms. It also updates the
behavior of the winrm upload communicator by allowing an array of paths
to be uploaded instead of a single file or folder to allow for this new
functionality for windows guests.
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.
Prior to this commit, if the ssh-config command was invoked within
cygwin or msys2, it would show a regular windows style path for private
keys rather than a path that could be used within msys2 or cygwin. This
commit updates that behavior by converting all of the private key paths
to the proper msys2 or cygwin path if the platform is windows and the
command was invoked from one of those two shells.
Prior to this commit, when the guest capability attempted to expand a
path with spaces it would quote the path passed in. However if the path
also had a relative path those quotes would end up making `printf`
ignore it and not properly expand the path fully. This commit updates
that to first escape the quotes of a path and then pass in the new path
to be expanded.
Prior to this commit, when using a global id to bring up a vagrant vm,
vagrant would fail during the "install provider" step due to the fact
that the global vagrant machine was not configured for the local vagrant
environment. Since this global vm exists elsewhere, we disable the
install provider step so that vagrant can just bring up the global
vagrant machine.
Prior to this commit, there was no way to add additional ssh arguments
within a Vagrantfile for a given vagrant machine. This commit introduces
a new option extra_args that allows users to pass in a single argument
or an array of flags that will be added onto the ssh command.
Prior to this commit, the `vagrant validate` command would only validate
the first machine in a vagrant file. This commit improves that by
validating all known machines in the environment. If one is not found,
it will properly throw an exception instead of a stacktrace.
Prior to this commit, if a user passed in a script that was frozen,
the shell provisioner would fail to modify the script to replace line
endings for windows because the string was immutable. This commit fixes
that by dup'ing the string so that it can have its line endings replaced
Prior to this commit, if a user set the `destination` path to include a
space, the `shell_expand_guest_path` function would remove that space
and return a partial path. This commit updates that to quote the path to
be expanded to preserve the entire path.
Prior to this commit, if a file provisioner block was ran twice with a
folder on a remote host, due to how scp works, it would first copy over
that folder, and then on the second action it would copy an identical
folder nested within the first one. While this is 'intended' behavior
with scp, it is unexpected behavior for the file provisioner. This
commit updates the file provisioner to first ensure that the directory
to be copied exists on the remote host prior to copying, and then the
destination dir has been changed to the directory that the destination
will be copied to, rather than the exact directly that includes the
folder from the host to prevent the nested folder behavior.
This adds a prompt for a token description, which is now supported in
Vagrant Cloud. Pressing enter on the prompt uses the default description
of `"Vagrant login"`.
$ vagrant login
In a moment we will ask for your username and password to HashiCorp's
Vagrant Cloud. After authenticating, we will store an access token locally on
disk. Your login details will be transmitted over a secure connection, and
are never stored on disk locally.
If you do not have an Vagrant Cloud account, sign up at
https://www.vagrantcloud.com
Vagrant Cloud Username: justincampbell
Password (will be hidden):
Token description (Defaults to "Vagrant login"):
You are now logged in.
$
Which created a token with the default description of "Vagrant login":
![](http://c.justincampbell.me/2V0p0T0U0d0O/Screen%20Shot%202017-08-10%20at%205.08.21%20PM.png)
Entering a description:
Token description (Defaults to "Vagrant login"): Justin's MacBook Pro
![](http://c.justincampbell.me/2m1N0d1M3k3P/Screen%20Shot%202017-08-10%20at%205.09.39%20PM.png)
Prior to this commit, if a state was reached where the action_box_add
command needed a force flag, it would fail requesting the user to
provide that flag to override adding a new box. However that flag did
not exist on the box update command, and could not be passed onto the
action_box_add action. This commit updates that to include a force flag,
and if used, pass that value onto the action_box_add action.
Prior to this commit, because of how the bootstrap salt shell file
worked, if github could not be resolved, the installer script would fail
silently with an exit code 0 because `sh` would evalute without any
errors and the curl exit code would be ignored. This commit splits out
the installer to first attempt to save the bash installer, and if it
exists, execute it.
Powershell helper script now returns error when guest IP address
cannot be discovered. When reading addresses from a network
device both IPv4 and IPv6 are stored and the IPv4 address has
precedence on returned address.
When preparing the NFS settings on VirtualBox the guest IP addresses
are pulled from VirtualBox directly and any static addresses are
pulled as well. This can lead to aquiring a host IP and machine IP
but results in a failure of NFS mount because the IPs are not on
the same network. This filters the machine IP result to validate
it is within the host adapter IP range.
Prior to this commit, the puppet provisioner would use the manifest dir
flag when running `puppet apply`. Not only is this flag redundant due to
how puppet apply works, but it is also deprecated in Puppet 4 and
removed in Puppet 5. This commit simply removes the flag when invoking
`puppet apply`.
Prior to this commit, rsync-auto would not properly rsync realtive dirs
outside the cwd if defined in the Vagrantfile. This commit updates that
to ensure that the command looks at the Vagrant config to ensure that
folder was intended to be rsync'd to the machine even if outside the
current working dir.
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.