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.
With this new option, it is now possible to pass additional arguments to
pip command when the `install_mode` is "pip".
(@gildegoma reworded the original commit message of pull request GH-8170)
With this new option defined, the `ansible-galaxy` and
`ansible-playbook` commands generated by the Ansible provisioners will
be executed with the ANSIBLE_CONFIG environment variable set
accordingly.
Resolve GH-7195
This commit also fix the following open issues:
- Implement the pending RSpec examples about path existence checks
performed by the ansible (remote) provisioner.
- In verbose mode, the ansible remote provisioner now correctly displays
the Ansible Galaxy parameters ("role_file" and "roles_path") with
single quotes (which is safer for potential copy-paste usage).
Additional Notes:
- Test coverage for `ansible_local` provisioner is still not
implemented. See GH-6633.
- Test coverage for galaxy from host is not implemented yet (due to
general issue with mocking both command executions, see
https://github.com/mitchellh/vagrant/pull/6529#r45278451
- Remove `ansible-galaxy` detection, since this command was introduced
in Ansible 1.4.2 (December 2013). Checking for `ansible-playbook`
presence should therefore be enough for any "modern" Ansible setup.
- Look for the command defined by the new `playbook_command` option.
Related to GH-7881 and GH-7536
This commit include the following changes:
- systematically set ANSIBLE_ROLES_PATH environment variable when
galaxy_roles_path is defined.
- slightly refactor to introduce the concept of "provisioning working
directory" (possible usage in the future for resolving GH-7195)
- fix a bug in ansible-galaxy execution by the ansible_local provisioner
if the paths contains blank characters.
Fix#7269
These changes have been validated against the following guest systems:
- Debian 7 and 8
- Ubuntu 12.04, 14.04 and 16.04
- Fedora 21 and 23
- CentOS 7
- OracleLinux 7
- Scientific Linux 7
At the moment, the pip setup (via get-pip.py script) is not working for
RHEL6-like systems (CentOS 6.6, OracleLinux 6.5, Scientific Linux 6),
because Python 2.6 has been deprecated and is no longer supported by
Python core team. I consider this limitation with low priority in
Vagrant context.
The `:pip` install_mode is currently not implemented for the following
platforms:
- OpenSUSE
- ArchLinux
- FreeBSD
Known Issue: By using get-pip.py script, any previous pip installation
will be most probably overrided. This could be an issue for Python
developers who would prefer to keep their base box setup untouched. In
future iteration, it could be possible to choose to reinstall/upgrade
pip or not. issue for Python developers who would prefer to keep their
base box setup untouched. In future iteration, it could be possible to
choose to reinstall/upgrade pip or not.
Resolve GH-6654
Resolve GH-7167 as the `version` option is now considered to select the
version of Ansible to be installed.
With this change, the presence of Ansible configuration files (like
playbook file, inventory path, galaxy role file, etc.) is no longer
performed by the `config` classes, but by the `provisioner` classes
(at the beginning of the provision command).
This change fixes several issues:
- Resolve#6984 as `provision` method are only executed when remote
(ssh) communication with the guest machine is possible.
- Resolve#6763 in a better way than 4e451c6 initially did.
- Improve the general provisioner speed since the `config` checks are
actually triggered by many vagrant actions (e.g. `destroy`,...), and
can also be triggered multiple times during a vagrant run (e.g. on
callback request made by the machine provider).
Unlike the former `config`-based checks, the provision action won't
collect all the invalid options, but only report the first invalid
option found and abort the execution.
Some unit tests were not implemented yet to save my scarce "open source
contribution time" for other important issues, but they should be done
at last via GH-6633.
This fixes a fairly large tempfile leak. Vagrant uses a template
renderer to write network configuration files locally to disk. Then,
that temporarily file is uploaded to the remote host and moved into
place. Since Vagrant is such a short-lived process, GC never came along
and cleaned up those tempfiles, resulting in many temporary files being
created through regular Vagrant usage.
The Util::Tempfile class uses a block to ensure the temporary file is
deleted when the block finishes. This API required small tweaks to the
usage, but provides more safety to ensure the files are deleted.
With cb80286a4a, the helper function
stringify_ansible_playbook_command was also applied on the
`raw_arguments` content, which is not wanted. Given that users have used
the `raw_arguments` option as a workaround to avoid the bug GH-6726,
this new change ensure that any `--extra-vars` option passed as a raw
argument won't be additonally enquoted by the ansible_local
provisioner.
This change also improves the ansible remote provisioner verbose output,
but has no impact on its behaviour, which was already correct.
Note that this refactoring introduces some code duplications that are not
very elegant (see ansible_playbook_command_for_shell_execution in
host.rb and execute_ansible_playbook_from_host in base.rb). I hope we
can find a better implementation later, but it is good enough for now
since all these parts are covered by corresponding unit tests (the
`ansible_local` stuff being tested via the verbose output of the ansible
remote provisioner).
At least for ansible 2.0.0.1 the command `ansible-galaxy --help` is inappropriate for testing if ansible is installed, as it yields an error:
```
vagrant@vagrant-ubuntu-trusty-64:~$ ansible-galaxy --help && echo "OK"
Usage: ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...
Options:
-h, --help show this help message and exit
-v, --verbose verbose mode (-vvv for more, -vvvv to enable connection
debugging)
--version show program's version number and exit
ERROR! Missing required action
```
Like in the (remote) `ansible` provisioner, it is preferred to pass the
directory that contains the generated inventory file. This way, advanced
inventory usages can be achieved by adding more inventory files into the
same directory.
Related to #2103 and #6500
[ci skip]
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.
Gilles Cornu
James Carr
Hanno Heinrichs
Seth Vargo
Daniel Schreiber
Christian Henz