2016-05-31 03:17:02 +00:00
|
|
|
require "tempfile"
|
|
|
|
|
2015-02-10 14:28:00 +00:00
|
|
|
require_relative "base"
|
|
|
|
|
|
|
|
module VagrantPlugins
|
|
|
|
module Ansible
|
|
|
|
module Provisioner
|
|
|
|
class Guest < Base
|
2016-05-29 03:17:40 +00:00
|
|
|
include Vagrant::Util
|
2015-02-10 14:28:00 +00:00
|
|
|
|
|
|
|
def initialize(machine, config)
|
|
|
|
super
|
2017-08-30 09:51:55 +00:00
|
|
|
@control_machine = "guest"
|
2015-02-10 14:28:00 +00:00
|
|
|
@logger = Log4r::Logger.new("vagrant::provisioners::ansible_guest")
|
|
|
|
end
|
|
|
|
|
|
|
|
def provision
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
check_files_existence
|
2017-09-01 18:45:10 +00:00
|
|
|
check_and_install_ansible
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
|
2015-11-17 21:06:06 +00:00
|
|
|
execute_ansible_galaxy_on_guest if config.galaxy_role_file
|
2015-02-10 14:28:00 +00:00
|
|
|
execute_ansible_playbook_on_guest
|
|
|
|
end
|
|
|
|
|
|
|
|
protected
|
|
|
|
|
|
|
|
#
|
|
|
|
# This handles verifying the Ansible installation, installing it if it was
|
|
|
|
# requested, and so on. This method will raise exceptions if things are wrong.
|
2017-09-01 18:45:10 +00:00
|
|
|
# The compatibility mode checks are also performed here in order to fetch the
|
|
|
|
# Ansible version information only once.
|
2015-02-10 14:28:00 +00:00
|
|
|
#
|
|
|
|
# Current limitations:
|
2017-09-01 16:24:01 +00:00
|
|
|
# - The installation of a specific Ansible version is only supported by
|
|
|
|
# the "pip" install_mode.
|
2017-09-06 12:30:56 +00:00
|
|
|
# - There is no absolute guarantee that the automated installation will replace
|
2017-09-01 16:24:01 +00:00
|
|
|
# a previous Ansible installation (although it works fine in many cases)
|
2015-02-10 14:28:00 +00:00
|
|
|
#
|
|
|
|
def check_and_install_ansible
|
|
|
|
@logger.info("Checking for Ansible installation...")
|
|
|
|
|
|
|
|
# If the guest cannot check if Ansible is installed,
|
|
|
|
# print a warning and try to continue without any installation attempt...
|
|
|
|
if !@machine.guest.capability?(:ansible_installed)
|
|
|
|
@machine.ui.warn(I18n.t("vagrant.provisioners.ansible.cannot_detect"))
|
|
|
|
return
|
|
|
|
end
|
|
|
|
|
|
|
|
# Try to install Ansible (if needed and requested)
|
|
|
|
if config.install &&
|
2015-11-12 08:09:58 +00:00
|
|
|
(config.version.to_s.to_sym == :latest ||
|
2015-02-10 14:28:00 +00:00
|
|
|
!@machine.guest.capability(:ansible_installed, config.version))
|
2015-11-18 08:37:27 +00:00
|
|
|
@machine.ui.detail I18n.t("vagrant.provisioners.ansible.installing")
|
2017-01-06 13:19:44 +00:00
|
|
|
@machine.guest.capability(:ansible_install, config.install_mode, config.version, config.pip_args)
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
|
2017-09-01 18:45:10 +00:00
|
|
|
# This step will also fetch the Ansible version data into related instance variables
|
|
|
|
set_and_check_compatibility_mode
|
2015-02-10 14:28:00 +00:00
|
|
|
|
|
|
|
# Check if requested ansible version is available
|
|
|
|
if (!config.version.empty? &&
|
2015-11-12 08:09:58 +00:00
|
|
|
config.version.to_s.to_sym != :latest &&
|
2017-09-01 18:45:10 +00:00
|
|
|
config.version != @gathered_version)
|
2017-09-01 06:05:50 +00:00
|
|
|
raise Ansible::Errors::AnsibleVersionMismatch,
|
|
|
|
system: @control_machine,
|
|
|
|
required_version: config.version,
|
|
|
|
current_version: @gathered_version
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
def gather_ansible_version
|
2017-09-01 06:05:50 +00:00
|
|
|
raw_output = ""
|
2017-09-01 18:45:10 +00:00
|
|
|
|
|
|
|
result = @machine.communicate.execute(
|
|
|
|
"ansible --version",
|
|
|
|
error_class: Ansible::Errors::AnsibleNotFoundOnGuest,
|
|
|
|
error_key: :ansible_not_found_on_guest) do |type, output|
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
if type == :stdout && output.lines[0]
|
|
|
|
raw_output = output.lines[0]
|
|
|
|
end
|
|
|
|
end
|
2017-09-01 18:45:10 +00:00
|
|
|
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
if result != 0
|
2017-09-01 06:05:50 +00:00
|
|
|
raw_output = ""
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
end
|
2017-09-01 18:45:10 +00:00
|
|
|
|
provisioners/ansible(both): Add compatibility mode
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.
2016-11-13 19:58:26 +00:00
|
|
|
raw_output
|
|
|
|
end
|
|
|
|
|
2016-06-11 05:28:05 +00:00
|
|
|
def get_provisioning_working_directory
|
|
|
|
config.provisioning_path
|
|
|
|
end
|
|
|
|
|
2015-11-17 21:06:06 +00:00
|
|
|
def execute_ansible_galaxy_on_guest
|
2016-09-20 20:58:41 +00:00
|
|
|
prepare_ansible_config_environment_variable
|
2016-04-23 22:26:59 +00:00
|
|
|
|
2016-09-20 20:58:41 +00:00
|
|
|
execute_ansible_command_on_guest "galaxy", ansible_galaxy_command_for_shell_execution
|
2015-11-17 21:06:06 +00:00
|
|
|
end
|
|
|
|
|
2015-02-10 14:28:00 +00:00
|
|
|
def execute_ansible_playbook_on_guest
|
2015-11-17 21:06:06 +00:00
|
|
|
prepare_common_command_arguments
|
|
|
|
prepare_common_environment_variables
|
|
|
|
|
2016-04-23 22:26:59 +00:00
|
|
|
execute_ansible_command_on_guest "playbook", ansible_playbook_command_for_shell_execution
|
2015-11-19 23:11:44 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
def execute_ansible_command_on_guest(name, command)
|
2016-04-23 22:26:59 +00:00
|
|
|
remote_command = "cd #{config.provisioning_path} && #{command}"
|
|
|
|
|
|
|
|
ui_running_ansible_command name, remote_command
|
2015-02-10 14:28:00 +00:00
|
|
|
|
2016-04-23 22:26:59 +00:00
|
|
|
result = execute_on_guest(remote_command)
|
2015-11-19 23:07:34 +00:00
|
|
|
raise Ansible::Errors::AnsibleCommandFailed if result != 0
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
def execute_on_guest(command)
|
2016-06-08 21:33:17 +00:00
|
|
|
@machine.communicate.execute(command, error_check: false) do |type, data|
|
2015-02-10 14:28:00 +00:00
|
|
|
if [:stderr, :stdout].include?(type)
|
2016-06-08 21:33:17 +00:00
|
|
|
@machine.env.ui.info(data, new_line: false, prefix: false)
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def ship_generated_inventory(inventory_content)
|
|
|
|
inventory_basedir = File.join(config.tmp_path, "inventory")
|
|
|
|
inventory_path = File.join(inventory_basedir, "vagrant_ansible_local_inventory")
|
|
|
|
|
2018-08-23 03:07:56 +00:00
|
|
|
@machine.communicate.sudo("mkdir -p #{inventory_path}")
|
2018-08-22 10:32:40 +00:00
|
|
|
@machine.communicate.sudo("chown -R -h #{@machine.ssh_info[:username]} #{config.tmp_path}")
|
2016-05-29 03:17:40 +00:00
|
|
|
@machine.communicate.sudo("rm -f #{inventory_path}", error_check: false)
|
|
|
|
|
2016-05-31 04:18:16 +00:00
|
|
|
Tempfile.open("vagrant-ansible-local-inventory-#{@machine.name}") do |f|
|
2016-05-31 03:17:02 +00:00
|
|
|
f.binmode
|
2016-05-29 03:17:40 +00:00
|
|
|
f.write(inventory_content)
|
|
|
|
f.fsync
|
|
|
|
f.close
|
|
|
|
@machine.communicate.upload(f.path, inventory_path)
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
|
2015-12-08 21:59:02 +00:00
|
|
|
return inventory_basedir
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
|
|
|
|
def generate_inventory_machines
|
|
|
|
machines = ""
|
|
|
|
|
|
|
|
# TODO: Instead, why not loop over active_machines and skip missing guests, like in Host?
|
|
|
|
machine.env.machine_names.each do |machine_name|
|
|
|
|
begin
|
|
|
|
@inventory_machines[machine_name] = machine_name
|
|
|
|
if @machine.name == machine_name
|
|
|
|
machines += "#{machine_name} ansible_connection=local\n"
|
|
|
|
else
|
|
|
|
machines += "#{machine_name}\n"
|
|
|
|
end
|
2015-12-01 17:15:40 +00:00
|
|
|
host_vars = get_inventory_host_vars_string(machine_name)
|
|
|
|
machines.sub!(/\n$/, " #{host_vars}\n") if host_vars
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
return machines
|
|
|
|
end
|
|
|
|
|
provisioners/ansible(both): fix ansible config files presence checks
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.
2016-05-31 22:30:07 +00:00
|
|
|
def check_path(path, test_args, option_name)
|
|
|
|
# Checks for the existence of given file (or directory) on the guest system,
|
|
|
|
# and error if it doesn't exist.
|
|
|
|
|
|
|
|
remote_path = Helpers::expand_path_in_unix_style(path, config.provisioning_path)
|
2016-10-21 14:38:02 +00:00
|
|
|
command = "test #{test_args} '#{remote_path}'"
|
provisioners/ansible(both): fix ansible config files presence checks
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.
2016-05-31 22:30:07 +00:00
|
|
|
|
|
|
|
@machine.communicate.execute(
|
|
|
|
command,
|
|
|
|
error_class: Ansible::Errors::AnsibleError,
|
|
|
|
error_key: :config_file_not_found,
|
|
|
|
config_option: option_name,
|
|
|
|
path: remote_path,
|
2017-08-30 09:51:55 +00:00
|
|
|
system: @control_machine
|
provisioners/ansible(both): fix ansible config files presence checks
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.
2016-05-31 22:30:07 +00:00
|
|
|
)
|
|
|
|
end
|
|
|
|
|
|
|
|
def check_path_is_a_file(path, error_message_key)
|
|
|
|
check_path(path, "-f", error_message_key)
|
|
|
|
end
|
|
|
|
|
|
|
|
def check_path_exists(path, error_message_key)
|
|
|
|
check_path(path, "-e", error_message_key)
|
|
|
|
end
|
|
|
|
|
2015-02-10 14:28:00 +00:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|