2016-05-25 07:12:14 +00:00
|
|
|
require_relative "../../../../base"
|
|
|
|
require_relative "../../support/shared/config"
|
|
|
|
require_relative "shared"
|
2015-11-20 23:13:35 +00:00
|
|
|
|
2015-02-10 14:28:00 +00:00
|
|
|
require Vagrant.source_root.join("plugins/provisioners/ansible/config/host")
|
2014-03-21 11:02:23 +00:00
|
|
|
|
2016-05-25 07:12:14 +00:00
|
|
|
describe VagrantPlugins::Ansible::Config::Host, :skip_windows => true do
|
2014-03-21 11:02:23 +00:00
|
|
|
include_context "unit"
|
|
|
|
|
|
|
|
subject { described_class.new }
|
|
|
|
|
|
|
|
let(:machine) { double("machine", env: Vagrant::Environment.new) }
|
2014-03-29 08:19:26 +00:00
|
|
|
let(:existing_file) { File.expand_path(__FILE__) }
|
|
|
|
|
|
|
|
it "supports a list of options" do
|
2017-08-29 03:32:38 +00:00
|
|
|
supported_options = %w(
|
|
|
|
ask_become_pass
|
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
|
|
|
ask_sudo_pass
|
2014-04-14 03:24:57 +00:00
|
|
|
ask_vault_pass
|
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
|
|
|
become
|
|
|
|
become_user
|
|
|
|
compatibility_mode
|
2016-09-20 20:58:41 +00:00
|
|
|
config_file
|
2014-03-29 08:19:26 +00:00
|
|
|
extra_vars
|
2015-11-02 08:03:15 +00:00
|
|
|
force_remote_user
|
2015-11-17 21:06:06 +00:00
|
|
|
galaxy_command
|
|
|
|
galaxy_role_file
|
|
|
|
galaxy_roles_path
|
2014-03-29 08:19:26 +00:00
|
|
|
groups
|
|
|
|
host_key_checking
|
2015-12-01 16:04:56 +00:00
|
|
|
host_vars
|
2014-03-29 08:19:26 +00:00
|
|
|
inventory_path
|
|
|
|
limit
|
|
|
|
playbook
|
2016-10-09 18:48:50 +00:00
|
|
|
playbook_command
|
2014-03-29 08:19:26 +00:00
|
|
|
raw_arguments
|
|
|
|
raw_ssh_args
|
|
|
|
skip_tags
|
|
|
|
start_at_task
|
|
|
|
sudo
|
|
|
|
sudo_user
|
|
|
|
tags
|
2014-04-14 03:24:57 +00:00
|
|
|
vault_password_file
|
2017-08-29 03:32:38 +00:00
|
|
|
verbose
|
|
|
|
version
|
|
|
|
)
|
2014-03-29 08:19:26 +00:00
|
|
|
|
2015-02-10 14:28:00 +00:00
|
|
|
expect(get_provisioner_option_names(described_class)).to eql(supported_options)
|
2014-03-29 08:19:26 +00:00
|
|
|
end
|
|
|
|
|
2016-05-25 07:12:14 +00:00
|
|
|
describe "default options handling" do
|
|
|
|
it_behaves_like "options shared by both Ansible provisioners"
|
|
|
|
|
|
|
|
it "assigns default values to unset host-specific options" do
|
|
|
|
subject.finalize!
|
|
|
|
|
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
|
|
|
expect(subject.ask_become_pass).to be(false)
|
|
|
|
expect(subject.ask_sudo_pass).to be(false) # deprecated
|
2017-04-06 21:57:46 +00:00
|
|
|
expect(subject.ask_vault_pass).to be(false)
|
|
|
|
expect(subject.force_remote_user).to be(true)
|
|
|
|
expect(subject.host_key_checking).to be(false)
|
2016-05-25 07:12:14 +00:00
|
|
|
expect(subject.raw_ssh_args).to be_nil
|
|
|
|
end
|
2014-03-29 08:19:26 +00:00
|
|
|
end
|
2014-03-21 11:02:23 +00:00
|
|
|
|
2015-11-02 08:03:15 +00:00
|
|
|
describe "force_remote_user option" do
|
|
|
|
it_behaves_like "any VagrantConfigProvisioner strict boolean attribute", :force_remote_user, true
|
|
|
|
end
|
2014-04-12 09:00:34 +00:00
|
|
|
describe "host_key_checking option" do
|
|
|
|
it_behaves_like "any VagrantConfigProvisioner strict boolean attribute", :host_key_checking, false
|
|
|
|
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
|
|
|
describe "ask_become_pass option" do
|
|
|
|
it_behaves_like "any VagrantConfigProvisioner strict boolean attribute", :ask_become_pass, false
|
|
|
|
end
|
2014-04-12 09:00:34 +00:00
|
|
|
describe "ask_sudo_pass option" do
|
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
|
|
|
before do
|
|
|
|
# Filter the deprecation notice
|
|
|
|
allow($stdout).to receive(:puts)
|
|
|
|
end
|
2014-04-12 09:00:34 +00:00
|
|
|
it_behaves_like "any VagrantConfigProvisioner strict boolean attribute", :ask_sudo_pass, false
|
2017-11-09 17:17:04 +00:00
|
|
|
it_behaves_like "any deprecated option", :ask_sudo_pass, :ask_become_pass, true
|
2014-04-12 09:00:34 +00:00
|
|
|
end
|
2014-04-14 03:24:57 +00:00
|
|
|
describe "ask_vault_pass option" do
|
2016-11-13 20:00:58 +00:00
|
|
|
it_behaves_like "any VagrantConfigProvisioner strict boolean attribute", :ask_vault_pass, false
|
2014-04-14 03:24:57 +00:00
|
|
|
end
|
2014-04-12 09:00:34 +00:00
|
|
|
|
2014-03-21 11:02:23 +00:00
|
|
|
describe "#validate" do
|
2014-03-29 08:19:26 +00:00
|
|
|
before do
|
|
|
|
subject.playbook = existing_file
|
|
|
|
end
|
|
|
|
|
2016-05-25 07:12:14 +00:00
|
|
|
it_behaves_like "an Ansible provisioner", "", "remote"
|
2014-03-21 11:02:23 +00:00
|
|
|
|
2016-04-20 20:27:55 +00:00
|
|
|
it "returns an error if the raw_ssh_args is of the wrong data type" do
|
|
|
|
subject.raw_ssh_args = { arg1: 1, arg2: "foo" }
|
|
|
|
subject.finalize!
|
|
|
|
|
|
|
|
result = subject.validate(machine)
|
|
|
|
expect(result["ansible remote provisioner"]).to eql([
|
|
|
|
I18n.t("vagrant.provisioners.ansible.errors.raw_ssh_args_invalid",
|
|
|
|
type: subject.raw_ssh_args.class.to_s,
|
|
|
|
value: subject.raw_ssh_args.to_s)
|
|
|
|
])
|
|
|
|
end
|
|
|
|
|
|
|
|
it "converts a raw_ssh_args option defined as a String into an Array" do
|
|
|
|
subject.raw_arguments = "-o ControlMaster=no"
|
|
|
|
subject.finalize!
|
|
|
|
|
|
|
|
result = subject.validate(machine)
|
|
|
|
expect(subject.raw_arguments).to eql(["-o ControlMaster=no"])
|
|
|
|
end
|
|
|
|
|
2014-03-21 11:02:23 +00:00
|
|
|
end
|
2014-03-29 08:19:26 +00:00
|
|
|
|
2014-03-21 11:02:23 +00:00
|
|
|
end
|