I missed to rename the refactored exceptions as AnsibleCommandFailed in
the guest-based parts. The lack of unit tests for these parts hurts...
on my agenda, I swear!
See c1f3d114f5
With this change, the existing host-based Ansible provisioner is
refactored to share a maximum of code with this new guest-based Ansible
provisioner.
At this stage of development, the existing unit tests are intentionally
modified as little as possible, to keep safe the existing funtionalities.
Other issues resolved by this changeset:
- Display a warning when running from a Windows host [GH-5292]
- Do not run `ansible-playbook` in verbose mode when the `verbose` option
is set to an empty string.
The benefits of the following "breaking change" are the following:
- default behaviour naturally fits with most common usage (i.e. always
connect with Vagrant SSH settings)
- the autogenerated inventory is more consistent by providing both the
SSH username and private key.
- no longer needed to explain how to override Ansible `remote_user` parameters
Important: With the `force_remote_user` option, people still can fall
back to the former behavior (prior to Vagrant 1.8.0), which means that
Vagrant integration capabilities are still quite open and flexible.
The problem demonstrated in #6065 is that a string has incorrectly been
encoded with US-ASCII even though it contains invalid US-ASCII byte
sequences (any byte with the most significant bit on is invalid in the
US-ASCII encoding).
The thing about doing newline normalization is that it is not actually
sensitive to the presence of US-ASCII byte sequenzes. Additionally, it
is very unlikely that a user will ever be using an encoding where \r\n
is not encoded the same as it would be in ASCII.
This patch first tries the existing method of normalizing the newlines
in the provided script file, if that fails for any reason it force
encodes the string to ASCII-8BIT (which allows the most significant bit
to be on in any individual byte) and then performs the substitution in
that byte space.
This allows Vagrant to calculate if a container's arguments (such as the run
arguments) have changed in the Vagrantfile since the original run.
Fixes GH-3055
When provisioning multiple machines in sequence (the default vagrant
behaviour), it doesn't make sense to require to provide the private ssh
key(s) via the custom ansible inventory script/file.
To align with the handling of multiple ssh keys per machine, we won't
rely any longer on `--private-key` command line argument, but only pass
the keys via `ANSIBLE_SSH_ARGS` environment variable.
Note that when vagrant generates the ansible inventory and that only one
key is associated to a VM, this step would be redundant, and therefore
won't be applied.
This change fixes the breaking change introduced by 3d62a91.
Vagrant 1.7.1 creates and injects new ssh keys for each virtual machine.
When it started ansible with the "parallel provisioning trick",
it would only send the ssh key of the targeted virtual machine.
With this change, vagrant now stores the ssh key for each virtual
machines directly in the generated ansible inventory, and thus allow
ansible parallelism.
Note that this change is not sufficient, as it would break vagrant
configuration based on a custom inventory (file or script). This issue
will be addressed in a next commit.
Signed-off-by: Luis Pabón <lpabon@redhat.com>
The Ansible Vagrant provisioner has a race where the inventory file is
updated every time the provisioner runs unless a file is provided.
Therefore if Ansible attempts to provision two nodes in parallel, you
may see the following race:
* System A writes the inventory file and calls Ansible.
* System B starts to provision and truncates the file before
creating a new one.
* Ansible on system A now attempts to read the inventory
file, which is blank. Ansible bombs out with "ERROR: provided
hosts list is empty".
To fix this, we only allow Vagrant to update the inventory file if
it needs to.
Revert 1c884fa4e5 which introduced the
following bug:
Instead of allowing to dump the `ansible-playbook` command details when
VAGRANT_LOG=debug was defined, it was then impossible to disable this
console output when VAGRANT_LOG was undefined (in such case,
``@logger.debug? systematically returns `true`)
In order to keep things simple and focused, it is preferable to drop the
bad idea to mix Ansible verbosity and Vagrant log level.
Fix#5803
Gilles Cornu
Sam Phippen
konomae
Jason Woods
지훈
Mitchell Hashimoto
Pat O'Shea
Mitchell Hashimoto
Ben Hines
William Kral
Seth Vargo
Luis Pabón
Nicholas Randon
Jeff Quast
arthurvanduynhoven