With the introduction of `pip_args` option, you can easily extend the
`:pip` installation mode behaviour. But some interesting/advanced usages
are still not possible because of the auto-generated parts ("ansible"
package, version selection, and the `--upgrade` flag).
By adding this "pip_args_only" install mode, it will be for instance
possible to:
- install unofficial releases, like release candidates published at
https://releases.ansible.com/
- install more pip packages (e.g. via a `requirements.txt` file), with
hash validation, etc.
Note that there is no config validation that requires `pip_args` option
to be defined when the :pip_args_only mode is selected. This would be
more elegant, and user friendly to raise a configuration error, but this
can wait. At least, running with an empty `pip_args` won't lead to any
command crash, since the rather dummy "pip install" shows an helper
notice and terminates with a zero (0) exit code.
This change is thought as a complement to the changes originally
proposed in pull request GH-8170.
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)
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.
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
Note that error messages were not adapted, and only mention
a generic "Ansible Software" when executed commands are failing.
We assume that people using the `playbook_command` option are
advanced users that will know all the components to be considered.
The ansible-playbook command is currently hardcoded for the ansible and
ansible_local provisioners. This patch adds the config option
playbook_command to allow the user to change the command.
Changes introduced in #7207 removed the logic to handle the
`minion_id` configuration. This commit addresses that regression
by including the `--id #{@config.minion_id}` flag everywhere that
`--local` is used (as it had done before).
I'm not totally in love with the `get_masterless` abstraction here,
so if someone has a better suggestion I'll happily change it.
Fixes#7454
- Honour `ssh.proxy_command` setting (even when the Docker provider is
used via a proxy host). Silly configurations may lead to silly
behaviors, but let's apply the settings...
- Remove condition on `provider_config.connect_via_ssh`, which is
a provider specific parameter (from vagrant-libvirt provider).
- Add a simple unit test
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.
Changes:
- Add "config" unit tests for `ansible_local` (guest)
- Share some "config" examples between both ansible provisioners
- Move `config_host.rb` specific examples to `config/host.rb`
- Add a requirement to "../helpers" in `config/guest.rb` in order to be
able to run the related unit tests
References:
- This is the first part of GH-6633 resolution
- This change is a handy prerequisite for GH-6570
Not addressed yet:
- FIXME (guest.rb): Some test-double stubs are currently not working as
expected, and the related checks are commented out for the moment
(no idea why, but this is not urgent to be fixed because of GH-7335
rejection. See also GH-6984)
- FIXME (shared.rb): The guest-based config should actually NOT return
an error when the extra_vars file cannot be found, but only display a
a warning (similarly to the changes done for GH-6763, see 4e451c6)
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 this change, the `raw_arguments` and `raw_ssh_args` options are:
- STILL automatically converted as an Array when they are set a String
(no behaviour change)
- rejected if they are not of Array data type otherwise
Additional Notes:
- the 'as_array' tiny helper has been removed since it was no longer
used.
- there is for now no deeper validation (i.e. verifying that the Array
elements are only *String* objects)
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).
The rationale here is to make it so existing Vagrantfile
configurations remain unchanged.
While benh57's solution worked for me, I had to add a
".to_yaml" to the VagrantFile line that implemented puppet.facter
and this would mean existing Vagrant configurations that use Puppet
would produce an error if that was not present.
Additionally, without this change, the Vagrant file also needed a
"require('yaml')" declaration to make the ".to_yaml" conversion
possible.
When updating the inventory, write to a temp file and replace the
original once writing is complete, to allow for an atomic replacement
of the contents.
Ensures that ansible reading an inventory file will get either the old
or new contents, but never the truncated version of the file that
appears should you open it with 'w' mode set to replace the contents.
Solves the 'provided hosts list is empty' error, which is emitted by
ansible should it manage to be reading the inventory file just as it
was truncated, but before the new contents were flushed to disk.
Partially-Fixes: #6526
Before this minor change, the '--limit' and '--start-at-task'
ansible-playbook command line arguments were enclosed into single
quotes. Using double quotes adds a bit more flexibility, especially
about the task name referred by `start_at_task` option.
It also aligns with the handling of the '--extra-vars' parameter
(see cb80286).
Without this change, the JSON string generated from the `extra_vars`
Ruby hash is passed without enclosing quotes and is then not parseable
by the ansible-playbook command when exectuted in a usual shell context.
In this changeset, the ansible (remote) unit test coverage is improved
to cover both usage of `extra_vars` (ansible_local unit tests are still
missing).
Additional Notes:
- Double quotes are favored to single quotes in order to allow usage of
any character for the variable values. For this reason additional
escaping is appended to JSON-inner double quotes and backslashes.
- This problem was not affecting the `ansible` remote provisioner
(which is running the ansible-playbook command via the childprocess
Ruby library). But with this change, the `verbose` output will also
now be correct for a copy-paste reuse.
- After this change, all the "--extra-vars" arguments (also a var
file passed with the @-syntax or anything coming via the
`raw_arguments` option) are "blindly" and systematically enclosed
in double quoted and double-escaped.
This is not optimal and can potentially break with peculiar values
(e.g. a double quote character (") cannot be used in a json value
when using `raw_arguments`). That said, I think that the current
solution is a reasonable trade-off, since the official `extra_vars`
option should now be able to cover a great majority of use cases.
Fix#6726
Previously the default channel was "current", but after discussion with
@coderanger on GH-6979, it seems like this was a poor design decision.
Instead, we should use the stable channel and allow users to opt-in to
prerelease versions.
Fixes GH-6979
Before this change, the detection of a non-existing path on the guest
machine was considered as an error and lead to interrupt the current vagrant
action. This was actually a mistake to do so, since the config checks
are performed before many other vagrant actions than `provision`.
The config.validate phase is also intended to primarily check the options
sanity, but it cannot be too strict with the guest state (which can easily
get "out of automatic control").
With this change, we still apply these checks (when possible), but only warn
about possible configuration problems. This way, the subsequent
statements will happen anyway (e.g. ansible commands will be
executed, vagrant machine will be destroyed, etc.)
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
```
In cd93721, I relied on a suprising combination of quotes to protect ssh
execution to strip the quoted path to the private key file.
Since any ssh command line argument can be passed via
`ANSIBLE_SSH_ARGS`, it is quite more readable and easy to rely on the
`-i` argument, which is not affected like `-o IdentityFile=...` and also
supports multiple occurences.
See also http://sourceforge.net/p/fuse/mailman/message/30498048/
Finally fix#6671
Note that I decided to not squash both commits for better
documentation and traceability.
Surprisingly (to me at least), a simple quote enclosure was not enough
to fix the problem.
Caveat: the stringified ansible-playbook command logged in verbose mode
is wrongly formatted (no quotes are escaped).
Fix#6671
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]
String and Symbol types are different when used as a Hash key. By
default the Vagrant machine names are set in Symbol format, but users
may write their `host_vars` entries with String keys. This is a very
simple way to ensure smooth experience, without having to coerce the
data types during the config validation (e.g. with a library like
Hashie, which is currently not in the Vagrant dependencies)
See also:
- https://bugs.ruby-lang.org/issues/5964#note-17
- https://github.com/intridea/hashie#keyconversion
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
This is required because the Chef Server almost always needs a node name to
interact. This will default to the hostname, but that's always going to be
`vagrant.vm`, which will collide easily.
This generates a random hostname with `vagrant-` as the prefix and stores the
result in the machine's data directory.
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 current docker installer attempt to install the linux-image-extra-`uname -r` DEB package on Debian systems.
This package may not exist, for example on custom kernels (e.g., Linode servers).
If this happens, Vagrant halts the provisioning. However, this package is not really needed in newer Debian releases (such as Ubuntu 14.04).
This small patch checks if the linux-image-extra-`uname -r` package exists, and it will install it if it does. In either case, it will continue provisioning.
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.
Starting with vagrant 1.7.3
(commit 1152b4e1df) we don't
save the command to be executed in the file anymore, but we send
it as a parameter, thus the back tick makes things worse.
puppet_server provisioner fails with Puppet Collection 1 with the
following error:
```bash
==> default: Running provisioner: puppet_server...
The `puppet` binary appears not to be in the PATH of the guest. This
could be because the PATH is not properly setup or perhaps Puppet is not
installed on this guest. Puppet provisioning can not continue without
Puppet properly installed.
```
Gilles Cornu
James Carr
Chris Roberts
Chris Roberts
Azul
Daniel Gonzalez
David Wittman
Dmitry Vasilets
Hanno Heinrichs
Seth Vargo
Luca Invernizzi
Thom May
Peter Carrero
Michael Sarahan
Darragh Bailey
Kamjar Gerami
Donald Guy
gavioto20
Daniel Schreiber
Shawn Neal
Gordon Franke
char16t
KaffeJunky123
Mitchell Hashimoto
michaa76
Rickard von Essen
Christian Henz
Jason Casden
Seth Miller
Mitchell Hashimoto
Aneesh Agrawal
Timotei Dolean
Dan Dunckel
Marc Siegfriedt
Johannes Graf