This bug (invalid method call) hasn't been caught by unit tests because
Vagrant::Plugin::V2::Config catches all invalid/bad configuration calls
and save them for generating error messages during the "validate" stage.
This way, the `ask_sudo_pass=(value)` method was not interrupted and the
`@ask_become_pass` attribute was (surprisingly) correctly set (allowing
the related unit tests to pass).
In order to avoid similar problem to happen again, the deprecation
message output is now fully verified.
This commit ensures that we actually break when the download was
successful. Before it tried to download again for every iteration of the
loop. In addition the number of iterations have been increased. I've
experienced timeouts on third retry. Increasing to 5.
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.
On Debian installations, wget is installed even into the most minimal
environment. Even Python support on Debian cannot be guaranteed if
Standard System Utilities was not selected at installation time (or if
debootstrap was used), which is why the retrieved bootstrap-salt.sh
script takes care of installing it prior to installing Salt.
This commit requires the winssh communicator class wihtin the public_key
capability for Windows. Prior to this commit users could run into a
situation where Vagrant would check if the machine could speak in WinSSH
and fail on an uninitialized constant.
This commit removes some duplicated code within the Solaris11 guest
implemnentation and instead relies on the Solaris guest for the majority
of its guest capabilities.
It should be valid to allow paths with spaces for the synced folder
guest path but since the guest path is used to generate the ID (if one
isn't provided), this will err out in VirtualBox because it doesn't
allow spaces for the --name argument. We should simply convert ' ' to
'_' as we do with other special characters.
Fixes#8991.
1. When remote executing scripts one should always call powershell with
1a. "-NonInteractive", in order to prevent interactive prompts from leading to an endless waiting time for the script to return
1b. "-NoProfile", in order to prevent the loading of unknown custom profiles before execution of the script which could have unintended side effects
2. During my tests I constantly ran into 408 timeouts when downloading the salt binaries. I've prevented that by adding a simple retry mechanism and an error exit in case of multiple failures. Without this change the bootstrap script never returned (and neither did vagrant up)
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":
Entering a description:
Token description (Defaults to "Vagrant login"): Justin's MacBook Pro
Zachary Flower
Gilles Cornu
Justin Campbell
Benjamin Schiborr
Brian Cain
Adam Bolte
Chris Roberts
Vít Ondruch
Bryce Shurts
Jonathan LaBroad
Ben Hines
Erik Lattimore
Björn Brala
Bryce Shurts
Mikhail Bulash
Jehiah Czebotar
Samuel Clark
nico.vanelslande
Chris Roberts
Antonio Terceiro
Dimitrios Kouzis-Loukas
Peter Parkkali
Rui Lopes
Taliesin Sisson
