2014-03-21 11:02:23 +00:00
require_relative " ../../../base "
2015-02-10 14:28:00 +00:00
require Vagrant . source_root . join ( " plugins/provisioners/ansible/config/host " )
require Vagrant . source_root . join ( " plugins/provisioners/ansible/provisioner/host " )
2014-03-21 11:02:23 +00:00
2014-03-29 08:19:26 +00:00
#
# Helper Functions
#
def find_last_argument_after ( ref_index , ansible_playbook_args , arg_pattern )
subset = ansible_playbook_args [ ( ref_index + 1 ) .. ( ansible_playbook_args . length - 2 ) ] . reverse
subset . each do | i |
return true if i =~ arg_pattern
end
return false
end
2015-02-10 14:28:00 +00:00
describe VagrantPlugins :: Ansible :: Provisioner :: Host do
2014-03-21 11:02:23 +00:00
include_context " unit "
subject { described_class . new ( machine , config ) }
let ( :iso_env ) do
2014-03-29 08:19:26 +00:00
# We have to create a Vagrantfile so there is a Vagrant Environment to provide:
# - a location for the generated inventory
# - multi-machines configuration
2014-03-21 11:02:23 +00:00
env = isolated_environment
2014-03-29 08:19:26 +00:00
env . vagrantfile ( <<-VF)
Vagrant . configure ( " 2 " ) do | config |
config . vm . box = " base "
config . vm . define :machine1
config . vm . define :machine2
end
VF
2014-03-21 11:02:23 +00:00
env . create_vagrant_env
end
let ( :machine ) { iso_env . machine ( iso_env . machine_names [ 0 ] , :dummy ) }
2015-02-10 14:28:00 +00:00
let ( :config ) { VagrantPlugins :: Ansible :: Config :: Host . new }
2014-03-21 11:02:23 +00:00
let ( :ssh_info ) { {
private_key_path : [ '/path/to/my/key' ] ,
2017-04-11 11:40:14 +00:00
keys_only : true ,
2014-03-29 08:19:26 +00:00
username : 'testuser' ,
host : '127.0.0.1' ,
port : 2223
2014-03-21 11:02:23 +00:00
} }
2017-04-06 21:57:46 +00:00
let ( :default_execute_result ) { Vagrant :: Util :: Subprocess :: Result . new ( 0 , " " , " " ) }
2014-03-21 11:02:23 +00:00
2014-03-29 08:19:26 +00:00
let ( :existing_file ) { File . expand_path ( __FILE__ ) }
2014-04-12 06:29:40 +00:00
let ( :generated_inventory_dir ) { File . join ( machine . env . local_data_path , %w( provisioners ansible inventory ) ) }
let ( :generated_inventory_file ) { File . join ( generated_inventory_dir , 'vagrant_ansible_inventory' ) }
2014-03-29 08:19:26 +00:00
2014-03-21 11:02:23 +00:00
before do
2017-04-06 21:57:46 +00:00
allow ( Vagrant :: Util :: Platform ) . to receive ( :solaris? ) . and_return ( false )
2014-11-25 07:12:43 +00:00
2017-04-06 21:57:46 +00:00
allow ( machine ) . to receive ( :ssh_info ) . and_return ( ssh_info )
allow ( machine . env ) . to receive ( :active_machines )
. and_return ( [ [ iso_env . machine_names [ 0 ] , :dummy ] , [ iso_env . machine_names [ 1 ] , :dummy ] ] )
2014-03-21 11:02:23 +00:00
2015-06-01 06:36:09 +00:00
stubbed_ui = Vagrant :: UI :: Colored . new
2017-04-06 21:57:46 +00:00
allow ( stubbed_ui ) . to receive ( :detail ) . and_return ( " " )
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
allow ( stubbed_ui ) . to receive ( :warn ) . and_return ( " " )
2017-04-06 21:57:46 +00:00
allow ( machine . env ) . to receive ( :ui ) . and_return ( stubbed_ui )
2015-06-01 06:36:09 +00:00
2014-03-22 16:18:00 +00:00
config . playbook = 'playbook.yml'
2014-03-21 11:02:23 +00:00
end
2014-03-29 08:19:26 +00:00
#
# Class methods for code reuse across examples
#
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 self . it_should_check_ansible_version ( )
it " execute 'ansible --version' before executing 'ansible-playbook' " do
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) .
once . with ( 'ansible' , '--version' , { :notify = > [ :stdout , :stderr ] } )
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) .
once . with ( 'ansible-playbook' , any_args )
end
end
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
def self . it_should_set_arguments_and_environment_variables (
2015-11-02 08:03:15 +00:00
expected_args_count = 5 ,
expected_vars_count = 4 ,
expected_host_key_checking = false ,
expected_transport_mode = " ssh " )
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
2014-03-29 08:19:26 +00:00
it " sets implicit arguments in a specific order " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-11-02 08:03:15 +00:00
expect ( args [ 1 ] ) . to eq ( " --connection=ssh " )
expect ( args [ 2 ] ) . to eq ( " --timeout=30 " )
2014-03-21 11:02:23 +00:00
2014-05-05 07:08:10 +00:00
inventory_count = args . count { | x | x =~ / ^--inventory-file=.+$ / }
2014-03-29 08:19:26 +00:00
expect ( inventory_count ) . to be > 0
2014-03-21 11:02:23 +00:00
2014-03-22 16:18:00 +00:00
expect ( args [ args . length - 2 ] ) . to eq ( " playbook.yml " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-21 11:02:23 +00:00
end
2014-04-26 12:08:10 +00:00
it " sets --limit argument " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-11-30 01:02:29 +00:00
all_limits = args . select { | x | x =~ / ^(--limit=|-l) / }
2014-04-26 12:08:10 +00:00
if config . raw_arguments
2014-05-05 07:08:10 +00:00
raw_limits = config . raw_arguments . select { | x | x =~ / ^(--limit=|-l) / }
2014-11-30 01:02:29 +00:00
expect ( all_limits . length - raw_limits . length ) . to eq ( 1 )
expect ( all_limits . last ) . to eq ( raw_limits . last )
2014-04-26 12:08:10 +00:00
else
2014-11-30 01:02:29 +00:00
if config . limit
limit = config . limit . kind_of? ( Array ) ? config . limit . join ( ',' ) : config . limit
expect ( all_limits . last ) . to eq ( " --limit= #{ limit } " )
else
expect ( all_limits . first ) . to eq ( " --limit= #{ machine . name } " )
end
2014-04-26 12:08:10 +00:00
end
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-04-26 12:08:10 +00:00
end
2014-03-29 08:19:26 +00:00
it " exports environment variables " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-21 11:02:23 +00:00
cmd_opts = args . last
2014-11-30 05:55:21 +00:00
if expected_host_key_checking
2015-01-12 07:58:29 +00:00
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to_not include ( " -o UserKnownHostsFile=/dev/null " )
2014-11-30 05:55:21 +00:00
else
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o UserKnownHostsFile=/dev/null " )
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
2015-01-12 07:58:29 +00:00
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o IdentitiesOnly=yes " )
2015-06-01 06:36:09 +00:00
expect ( cmd_opts [ :env ] [ 'ANSIBLE_FORCE_COLOR' ] ) . to eql ( " true " )
expect ( cmd_opts [ :env ] ) . to_not include ( " ANSIBLE_NOCOLOR " )
2014-03-29 08:19:26 +00:00
expect ( cmd_opts [ :env ] [ 'ANSIBLE_HOST_KEY_CHECKING' ] ) . to eql ( expected_host_key_checking . to_s )
2014-03-21 11:02:23 +00:00
expect ( cmd_opts [ :env ] [ 'PYTHONUNBUFFERED' ] ) . to eql ( 1 )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-21 11:02:23 +00:00
end
2014-03-29 08:19:26 +00:00
# "roughly" verify that only expected args/vars have been defined by the provisioner
it " sets the expected number of arguments and environment variables " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
expect ( args . length - 2 ) . to eq ( expected_args_count )
2014-03-29 08:19:26 +00:00
expect ( args . last [ :env ] . length ) . to eq ( expected_vars_count )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
2015-11-22 19:48:21 +00:00
it " enables ' #{ expected_transport_mode } ' as default transport mode " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
index = args . rindex ( " --connection= #{ expected_transport_mode } " )
expect ( index ) . to be > 0
2017-04-06 21:57:46 +00:00
expect ( find_last_argument_after ( index , args , / --connection= \ w+ / ) ) . to be ( false )
} . and_return ( default_execute_result )
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
end
2014-03-21 11:02:23 +00:00
end
2014-03-29 08:19:26 +00:00
def self . it_should_set_optional_arguments ( arg_map )
it " sets optional arguments " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
arg_map . each_pair do | vagrant_option , ansible_argument |
index = args . index ( ansible_argument )
if config . send ( vagrant_option )
expect ( index ) . to be > 0
else
expect ( index ) . to be_nil
end
end
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
end
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
def self . it_should_explicitly_enable_ansible_ssh_control_persist_defaults
2014-03-29 08:19:26 +00:00
it " configures ControlPersist (like Ansible defaults) via ANSIBLE_SSH_ARGS " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-21 11:02:23 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o ControlMaster=auto " )
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o ControlPersist=60s " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-21 11:02:23 +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 self . it_should_create_and_use_generated_inventory ( with_user = true )
2014-03-29 08:19:26 +00:00
it " generates an inventory with all active machines " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
expect ( config . inventory_path ) . to be_nil
2017-04-06 21:57:46 +00:00
expect ( File . exists? ( generated_inventory_file ) ) . to be ( true )
2014-03-29 08:19:26 +00:00
inventory_content = File . read ( generated_inventory_file )
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
_ssh = config . compatibility_mode == VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V2_0 ? " " : " _ssh "
if with_user
expect ( inventory_content ) . to include ( " #{ machine . name } ansible #{ _ssh } _host= #{ machine . ssh_info [ :host ] } ansible #{ _ssh } _port= #{ machine . ssh_info [ :port ] } ansible #{ _ssh } _user=' #{ machine . ssh_info [ :username ] } ' ansible_ssh_private_key_file=' #{ machine . ssh_info [ :private_key_path ] [ 0 ] } ' \n " )
2015-11-02 08:03:15 +00:00
else
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 ( inventory_content ) . to include ( " #{ machine . name } ansible #{ _ssh } _host= #{ machine . ssh_info [ :host ] } ansible #{ _ssh } _port= #{ machine . ssh_info [ :port ] } ansible_ssh_private_key_file=' #{ machine . ssh_info [ :private_key_path ] [ 0 ] } ' \n " )
2015-11-02 08:03:15 +00:00
end
2014-03-29 08:19:26 +00:00
expect ( inventory_content ) . to include ( " # MISSING: ' #{ iso_env . machine_names [ 1 ] } ' machine was probably removed without using Vagrant. This machine should be recreated. \n " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
2014-04-12 06:29:40 +00:00
it " sets as ansible inventory the directory containing the auto-generated inventory file " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-04-12 06:29:40 +00:00
inventory_index = args . rindex ( " --inventory-file= #{ generated_inventory_dir } " )
2014-03-29 08:19:26 +00:00
expect ( inventory_index ) . to be > 0
2017-04-06 21:57:46 +00:00
expect ( find_last_argument_after ( inventory_index , args , / --inventory-file= \ w+ / ) ) . to be ( false )
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
end
2017-11-10 19:40:13 +00:00
def ensure_that_config_is_valid
# Abort the test when an invalid configuration is detected
config . validate ( machine )
if config . _detected_errors . length > 0
raise " Invalid Provisioner Configuration! Detected Errors: \n #{ config . _detected_errors . to_s } "
end
end
2014-03-21 11:02:23 +00:00
describe " # provision " do
before do
2017-04-06 21:57:46 +00:00
unless RSpec . current_example . metadata [ :skip_before ]
2014-03-22 16:18:00 +00:00
config . finalize!
2016-09-20 20:58:41 +00:00
2017-04-06 21:57:46 +00:00
allow ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. and_return ( Vagrant :: Util :: Subprocess :: Result . new ( 0 , " " , " " ) )
allow ( subject ) . to receive ( :check_path )
2014-03-22 16:18:00 +00:00
end
end
after do
2017-04-06 21:57:46 +00:00
unless RSpec . current_example . metadata [ :skip_after ]
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
2014-03-22 16:18:00 +00:00
subject . provision
end
2014-03-21 11:02:23 +00:00
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
describe 'checking existence of Ansible configuration files' do
2016-09-20 20:58:41 +00:00
STUBBED_INVALID_PATH = " /test/239nfmd/invalid_path " . freeze
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
2016-09-20 20:58:41 +00:00
it 'raises an error when the `playbook` file does not exist' , skip_before : true , skip_after : true do
2017-04-06 21:57:46 +00:00
allow ( subject ) . to receive ( :check_path ) . and_raise ( VagrantPlugins :: Ansible :: Errors :: AnsibleError ,
2016-09-20 20:58:41 +00:00
_key : :config_file_not_found ,
config_option : " playbook " ,
path : STUBBED_INVALID_PATH ,
system : " host " )
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
2016-09-20 20:58:41 +00:00
config . playbook = STUBBED_INVALID_PATH
config . finalize!
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
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
2016-09-20 20:58:41 +00:00
expect { subject . provision } . to raise_error ( VagrantPlugins :: Ansible :: Errors :: AnsibleError ,
" `playbook` does not exist on the host: #{ STUBBED_INVALID_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
end
2016-09-20 20:58:41 +00:00
%w( config_file extra_vars inventory_path galaxy_role_file vault_password_file ) . each do | option_name |
it " raises an error when the ' #{ option_name } ' does not exist " , skip_before : true , skip_after : true do
2017-04-06 21:57:46 +00:00
allow ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. and_return ( Vagrant :: Util :: Subprocess :: Result . new ( 0 , " " , " " ) )
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
2016-09-20 20:58:41 +00:00
config . playbook = existing_file
config . send ( option_name + '=' , STUBBED_INVALID_PATH )
config . finalize!
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
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
2016-09-20 20:58:41 +00:00
expect { subject . provision } . to raise_error ( VagrantPlugins :: Ansible :: Errors :: AnsibleError ,
" ` #{ option_name } ` does not exist on the host: #{ STUBBED_INVALID_PATH } " )
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
end
end
2014-03-29 08:19:26 +00:00
describe 'when ansible-playbook fails' do
it " raises an error " , skip_before : true , skip_after : true do
config . finalize!
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
2016-09-20 20:58:41 +00:00
2017-04-06 21:57:46 +00:00
allow ( subject ) . to receive ( :check_path )
2017-08-14 16:54:33 +00:00
allow ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. and_return ( Vagrant :: Util :: Subprocess :: Result . new ( 1 , " " , " " ) )
2014-03-29 08:19:26 +00:00
2015-11-17 21:06:06 +00:00
expect { subject . provision } . to raise_error ( VagrantPlugins :: Ansible :: Errors :: AnsibleCommandFailed )
2014-03-29 08:19:26 +00:00
end
2014-03-21 11:02:23 +00:00
end
2014-03-29 08:19:26 +00:00
describe " with default options " 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
it_should_check_ansible_version
2014-03-29 08:19:26 +00:00
it_should_set_arguments_and_environment_variables
it_should_create_and_use_generated_inventory
2014-03-21 11:02:23 +00:00
2014-03-29 08:19:26 +00:00
it " does not add any group section to the generated inventory " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) {
2014-03-29 08:19:26 +00:00
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to_not match ( / ^ \ s* \ [^ \\ + \ ] \ s*$ / )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
2014-03-31 14:25:16 +00:00
2015-02-10 14:28:00 +00:00
it " doesn't show the ansible-playbook command " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to_not receive ( :detail ) . with ( / ansible-playbook / )
2014-03-31 14:25:16 +00:00
end
2014-03-21 11:02:23 +00:00
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 " deprecated 'sudo' options are aliases for equivalent 'become' options " do
before do
# Filter the deprecation notices
allow ( $stdout ) . to receive ( :puts )
config . sudo = true
config . sudo_user = 'deployer'
config . ask_sudo_pass = true
end
it_should_set_optional_arguments ( { " sudo " = > " --sudo " ,
" sudo_user " = > " --sudo-user=deployer " ,
" ask_sudo_pass " = > " --ask-sudo-pass " ,
" become " = > " --sudo " ,
" become_user " = > " --sudo-user=deployer " ,
" ask_become_pass " = > " --ask-sudo-pass " } )
end
2017-08-26 06:47:35 +00:00
context " with compatibility_mode 'auto' " 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
2017-08-26 06:47:35 +00:00
config . compatibility_mode = VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_AUTO
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
valid_versions = {
" 0.6 " : VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V1_8 ,
" 1.9.4 " : VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V1_8 ,
2017-09-01 06:05:50 +00:00
" 2.5.0.0-rc1 " : VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V2_0 ,
" 2.x.y.z " : VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V2_0 ,
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
" 4.3.2.1 " : VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V2_0 ,
}
valid_versions . each_pair do | ansible_version , mode |
describe " and ansible version #{ ansible_version } " do
before do
2017-08-29 03:40:25 +00:00
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " ansible #{ ansible_version } \n ... \n " )
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
it " detects the compatibility mode #{ mode } " do
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
expect ( config . compatibility_mode ) . to eq ( mode )
} . and_return ( default_execute_result )
end
it " warns about compatibility mode auto-detection being used " do
expect ( machine . env . ui ) . to receive ( :warn ) . with (
I18n . t ( " vagrant.provisioners.ansible.compatibility_mode_warning " ,
2017-09-01 06:05:50 +00:00
compatibility_mode : mode , ansible_version : ansible_version ) +
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
" \n " )
end
end
end
invalid_versions = [
" ansible devel " ,
2017-09-01 06:05:50 +00:00
" anything 1.2 " ,
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
" 2.9.2.1 " ,
]
invalid_versions . each do | unknown_ansible_version |
describe " and `ansible --version` returning ' #{ unknown_ansible_version } ' " do
before do
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( unknown_ansible_version )
end
2017-08-26 06:47:35 +00:00
it " applies the safest compatibility mode (' #{ VagrantPlugins :: Ansible :: SAFE_COMPATIBILITY_MODE } ') " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2017-08-26 06:47:35 +00:00
expect ( config . compatibility_mode ) . to eq ( VagrantPlugins :: Ansible :: SAFE_COMPATIBILITY_MODE )
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
} . and_return ( default_execute_result )
end
it " warns about not being able to detect the best compatibility mode " do
expect ( machine . env . ui ) . to receive ( :warn ) . with (
I18n . t ( " vagrant.provisioners.ansible.compatibility_mode_not_detected " ,
2017-08-26 06:47:35 +00:00
compatibility_mode : VagrantPlugins :: Ansible :: SAFE_COMPATIBILITY_MODE ,
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
gathered_version : unknown_ansible_version ) +
" \n " )
end
end
end
end
context " with compatibility_mode ' #{ VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V1_8 } ' " do
before do
config . compatibility_mode = VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V1_8
end
2017-09-01 06:05:50 +00:00
it_should_check_ansible_version
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
it_should_create_and_use_generated_inventory
it " doesn't warn about compatibility mode auto-detection " do
expect ( machine . env . ui ) . to_not receive ( :warn )
end
end
context " with compatibility_mode ' #{ VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V2_0 } ' " do
before do
config . compatibility_mode = VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V2_0
2017-09-01 06:05:50 +00:00
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " ansible 2.3.0.0 \n ... \n " )
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
it_should_create_and_use_generated_inventory
it " doesn't warn about compatibility mode auto-detection " do
expect ( machine . env . ui ) . to_not receive ( :warn )
end
2017-09-01 06:05:50 +00:00
describe " and an incompatible ansible version " do
before do
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " ansible 1.9.3 \n ... \n " )
end
it " raises a compatibility conflict error " , skip_before : false , skip_after : true do
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
2017-09-01 06:05:50 +00:00
expect { subject . provision } . to raise_error ( VagrantPlugins :: Ansible :: Errors :: AnsibleCompatibilityModeConflict )
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
describe " deprecated 'sudo' options are aliases for equivalent 'become' options " do
before do
# Filter the deprecation notices
allow ( $stdout ) . to receive ( :puts )
config . sudo = true
config . sudo_user = 'deployer'
config . ask_sudo_pass = true
end
it_should_set_optional_arguments ( { " sudo " = > " --become " ,
" sudo_user " = > " --become-user=deployer " ,
" ask_sudo_pass " = > " --ask-become-pass " ,
" become " = > " --become " ,
" become_user " = > " --become-user=deployer " ,
" ask_become_pass " = > " --ask-become-pass " } )
end
end
2016-10-10 14:56:36 +00:00
describe " with playbook_command option " do
before do
config . playbook_command = " custom-ansible-playbook "
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
2018-03-14 14:41:04 +00:00
# set the compatibility mode to ensure that only ansible-playbook is executed
2017-09-01 06:05:50 +00:00
config . compatibility_mode = VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V1_8
2016-10-10 14:56:36 +00:00
end
it " uses custom playbook_command to run playbooks " do
2017-08-14 16:54:33 +00:00
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. with ( " custom-ansible-playbook " , any_args )
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
. and_return ( default_execute_result )
2016-10-10 14:56:36 +00:00
end
end
2015-12-01 16:04:56 +00:00
describe " with host_vars option " do
it_should_create_and_use_generated_inventory
2015-12-02 07:42:44 +00:00
it " adds host variables (given in Hash format) to the generated inventory " do
2015-12-01 16:04:56 +00:00
config . host_vars = {
2017-09-06 19:22:41 +00:00
machine1 : {
" http_port " = > 80 ,
" comments " = > " 'some text with spaces and quotes' " ,
" description " = > " text with spaces but no quotes " ,
}
2015-12-02 07:42:44 +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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) {
2015-12-02 07:42:44 +00:00
inventory_content = File . read ( generated_inventory_file )
2017-09-06 19:22:41 +00:00
expect ( inventory_content ) . to match ( " ^ " + Regexp . quote ( machine . name ) + " .+http_port=80 comments='some text with spaces and quotes' description='text with spaces but no quotes' " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-12-02 07:42:44 +00:00
end
it " adds host variables (given in Array format) to the generated inventory " do
config . host_vars = {
machine1 : [ " http_port=80 " , " maxRequestsPerChild=808 " ]
}
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 ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) {
2015-12-02 07:42:44 +00:00
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to match ( " ^ " + Regexp . quote ( machine . name ) + " .+http_port=80 maxRequestsPerChild=808 " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-12-02 07:42:44 +00:00
end
it " adds host variables (given in String format) to the generated inventory " do
config . host_vars = {
:machine1 = > " http_port=80 maxRequestsPerChild=808 "
2015-12-01 16:04:56 +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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) {
2015-12-01 16:04:56 +00:00
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to match ( " ^ " + Regexp . quote ( machine . name ) + " .+http_port=80 maxRequestsPerChild=808 " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-12-02 07:37:41 +00:00
end
it " retrieves the host variables by machine name, also in String format " do
config . host_vars = {
" machine1 " = > " http_port=80 maxRequestsPerChild=808 "
}
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 ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) {
2015-12-02 07:37:41 +00:00
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to match ( " ^ " + Regexp . quote ( machine . name ) + " .+http_port=80 maxRequestsPerChild=808 " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-12-01 16:04:56 +00:00
end
end
2014-03-29 08:19:26 +00:00
describe " with groups option " do
it_should_create_and_use_generated_inventory
it " adds group sections to the generated inventory " do
config . groups = {
2015-12-03 08:39:12 +00:00
" group1 " = > " machine1 " ,
" group1:children " = > 'bar group3' ,
2014-04-25 20:11:13 +00:00
" group2 " = > [ iso_env . machine_names [ 1 ] ] ,
2014-03-29 08:19:26 +00:00
" group3 " = > [ " unknown " , " #{ machine . name } " ] ,
2015-12-03 20:07:05 +00:00
" group4 " = > [ " machine[1:2] " , " machine[a:f] " ] ,
2015-12-04 01:16:01 +00:00
" group6 " = > [ machine . name ] ,
2014-03-29 08:19:26 +00:00
" bar " = > [ " #{ machine . name } " , " group3 " ] ,
2015-12-03 08:39:12 +00:00
" bar:children " = > [ " group1 " , " group2 " , " group3 " , " group5 " ] ,
2014-03-29 08:19:26 +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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
inventory_content = File . read ( generated_inventory_file )
2015-12-03 08:39:12 +00:00
# Accept String instead of Array for group member list
expect ( inventory_content ) . to include ( " [group1] \n machine1 \n \n " )
expect ( inventory_content ) . to include ( " [group1:children] \n bar \n group3 \n \n " )
2014-03-29 08:19:26 +00:00
# Skip "lost" machines
expect ( inventory_content ) . to include ( " [group2] \n \n " )
2014-03-22 16:18:00 +00:00
2014-03-29 08:19:26 +00:00
# Skip "unknown" machines
2015-12-03 08:39:12 +00:00
expect ( inventory_content ) . to include ( " [group3] \n #{ machine . name } \n \n " )
2014-03-21 11:02:23 +00:00
2015-12-03 08:34:53 +00:00
# Accept Symbol datatype for group names
2015-12-04 01:16:01 +00:00
expect ( inventory_content ) . to include ( " [group6] \n #{ machine . name } \n \n " )
2015-12-03 08:34:53 +00:00
2015-12-03 20:07:05 +00:00
# Accept host range patterns
expect ( inventory_content ) . to include ( " [group4] \n machine[1:2] \n machine[a:f] \n " )
2014-03-29 08:19:26 +00:00
# Don't mix group names and host names
2015-12-03 08:39:12 +00:00
expect ( inventory_content ) . to include ( " [bar] \n #{ machine . name } \n \n " )
2014-03-29 08:19:26 +00:00
# A group of groups only includes declared groups
2015-12-03 08:39:12 +00:00
expect ( inventory_content ) . not_to include ( " group5 " )
expect ( inventory_content ) . to match ( Regexp . quote ( " [bar:children] \n group1 \n group2 \n group3 \n " ) + " $ " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
2015-12-01 13:25:41 +00:00
it " adds group vars to the generated inventory " do
config . groups = {
" group1 " = > [ machine . name ] ,
" group2 " = > [ machine . name ] ,
" group3 " = > [ machine . name ] ,
" group1:vars " = > { " hashvar1 " = > " hashvalue1 " , " hashvar2 " = > " hashvalue2 " } ,
" group2:vars " = > [ " arrayvar1=arrayvalue1 " , " arrayvar2=arrayvalue2 " ] ,
" group3:vars " = > " stringvar1=stringvalue1 stringvar2=stringvalue2 " ,
}
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 ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-12-01 13:25:41 +00:00
inventory_content = File . read ( generated_inventory_file )
# Hash syntax
expect ( inventory_content ) . to include ( " [group1:vars] \n hashvar1=hashvalue1 \n hashvar2=hashvalue2 \n " )
# Array syntax
expect ( inventory_content ) . to include ( " [group2:vars] \n arrayvar1=arrayvalue1 \n arrayvar2=arrayvalue2 \n " )
# Single string syntax
expect ( inventory_content ) . to include ( " [group3:vars] \n stringvar1=stringvalue1 \n stringvar2=stringvalue2 \n " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-12-01 13:25:41 +00:00
end
2017-09-03 15:09:16 +00:00
it " adds 'all:vars' section to the generated inventory " do
config . groups = {
" all:vars " = > { " var1 " = > " value1 " , " var2 " = > " value2 " }
}
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to include ( " [all:vars] \n var1=value1 \n var2=value2 \n " )
} . and_return ( default_execute_result )
end
2014-03-29 08:19:26 +00:00
end
describe " with host_key_checking option enabled " do
before do
2014-04-12 09:00:34 +00:00
config . host_key_checking = true
2014-03-29 08:19:26 +00:00
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables 5 , 4 , true
2014-03-29 08:19:26 +00:00
end
describe " with boolean (flag) options disabled " do
before 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
config . become = false
config . ask_become_pass = false
2014-04-14 08:29:10 +00:00
config . ask_vault_pass = false
2014-03-29 08:19:26 +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
config . become_user = 'root'
2014-03-29 08:19:26 +00:00
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables 6
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
it_should_set_optional_arguments ( { " become_user " = > " --sudo-user=root " } )
2014-03-29 08:19:26 +00:00
it " it does not set boolean flag when corresponding option is set to false " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
expect ( args . index ( " --sudo " ) ) . to be_nil
expect ( args . index ( " --ask-sudo-pass " ) ) . to be_nil
2014-04-14 08:29:10 +00:00
expect ( args . index ( " --ask-vault-pass " ) ) . to be_nil
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
end
describe " with raw_arguments option " do
before 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
config . become = false
2015-11-02 08:03:15 +00:00
config . force_remote_user = false
2014-03-29 08:19:26 +00:00
config . skip_tags = %w( foo bar )
2014-11-30 01:02:29 +00:00
config . limit = " all "
2014-03-29 08:19:26 +00:00
config . raw_arguments = [ " --connection=paramiko " ,
" --skip-tags=ignored " ,
" --module-path=/other/modules " ,
" --sudo " ,
2014-04-26 12:08:10 +00:00
" -l localhost " ,
" --limit=foo " ,
" --limit=bar " ,
2014-03-29 08:19:26 +00:00
" --inventory-file=/forget/it/my/friend " ,
2014-11-30 01:02:29 +00:00
" --user=lion " ,
2014-03-29 08:19:26 +00:00
" --new-arg=yeah " ]
end
2014-12-22 04:13:14 +00:00
it_should_set_arguments_and_environment_variables 17 , 4 , false , " paramiko "
2014-03-29 08:19:26 +00:00
it " sets all raw arguments " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
config . raw_arguments . each do | raw_arg |
expect ( args ) . to include ( raw_arg )
end
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
2014-11-30 01:02:29 +00:00
it " sets raw arguments after arguments related to supported options " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-11-30 01:02:29 +00:00
expect ( args . index ( " --user=lion " ) ) . to be > args . index ( " --user=testuser " )
expect ( args . index ( " --inventory-file=/forget/it/my/friend " ) ) . to be > args . index ( " --inventory-file= #{ generated_inventory_dir } " )
expect ( args . index ( " --limit=bar " ) ) . to be > args . index ( " --limit=all " )
expect ( args . index ( " --skip-tags=ignored " ) ) . to be > args . index ( " --skip-tags=foo,bar " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
it " sets boolean flag (e.g. --sudo) defined in raw_arguments, even if corresponding option is set to false " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
expect ( args ) . to include ( '--sudo' )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
end
describe " with limit option " do
before do
config . limit = %w( foo !bar )
end
2014-04-26 12:08:10 +00:00
it_should_set_arguments_and_environment_variables
2014-03-22 16:18:00 +00:00
end
2015-11-02 08:03:15 +00:00
context " with force_remote_user option disabled " do
before do
config . force_remote_user = false
end
it_should_create_and_use_generated_inventory false # i.e. without setting ansible_ssh_user in inventory
it_should_set_arguments_and_environment_variables 6
it " uses a --user argument to set a default remote user " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-11-02 08:03:15 +00:00
expect ( args ) . not_to include ( " --extra-vars=ansible_ssh_user=' #{ machine . ssh_info [ :username ] } ' " )
expect ( args ) . to include ( " --user= #{ machine . ssh_info [ :username ] } " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-11-02 08:03:15 +00:00
end
end
2015-11-22 19:48:21 +00:00
context " with winrm communicator " do
let ( :iso_winrm_env ) do
env = isolated_environment
env . vagrantfile <<-VF
Vagrant . configure ( " 2 " ) do | config |
config . winrm . username = 'winner'
config . winrm . password = 'winword'
config . winrm . transport = :ssl
config . vm . define :machine1 do | machine |
machine . vm . box = " winbox "
machine . vm . communicator = :winrm
end
end
VF
env . create_vagrant_env
end
let ( :machine ) { iso_winrm_env . machine ( iso_winrm_env . machine_names [ 0 ] , :dummy ) }
it_should_set_arguments_and_environment_variables
it " generates an inventory with winrm connection settings " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-11-22 19:48:21 +00:00
expect ( config . inventory_path ) . to be_nil
2017-04-06 21:57:46 +00:00
expect ( File . exists? ( generated_inventory_file ) ) . to be ( true )
2015-11-22 19:48:21 +00:00
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to include ( " machine1 ansible_connection=winrm ansible_ssh_host=127.0.0.1 ansible_ssh_port=55986 ansible_ssh_user='winner' ansible_ssh_pass='winword' \n " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-11-22 19:48:21 +00:00
end
2015-11-23 08:05:36 +00:00
describe " with force_remote_user option disabled " do
before do
config . force_remote_user = false
end
2015-11-23 08:12:56 +00:00
it " doesn't set the ansible remote user in inventory and use '--user' argument with the vagrant ssh username " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-11-23 08:05:36 +00:00
inventory_content = File . read ( generated_inventory_file )
expect ( inventory_content ) . to include ( " machine1 ansible_connection=winrm ansible_ssh_host=127.0.0.1 ansible_ssh_port=55986 ansible_ssh_pass='winword' \n " )
expect ( args ) . to include ( " --user=testuser " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-11-23 08:05:36 +00:00
end
end
2015-11-22 19:48:21 +00:00
end
2014-03-22 16:18:00 +00:00
describe " with inventory_path option " do
before do
2014-03-29 08:19:26 +00:00
config . inventory_path = existing_file
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables 6
2014-03-29 08:19:26 +00:00
it " does not generate the inventory and uses given inventory path instead " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
expect ( args ) . to include ( " --inventory-file= #{ existing_file } " )
expect ( args ) . not_to include ( " --inventory-file= #{ generated_inventory_file } " )
2017-04-06 21:57:46 +00:00
expect ( File . exists? ( generated_inventory_file ) ) . to be ( false )
} . and_return ( default_execute_result )
2014-03-29 08:19:26 +00:00
end
2015-11-02 08:03:15 +00:00
it " uses an --extra-vars argument to force ansible_ssh_user parameter " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-11-02 08:03:15 +00:00
expect ( args ) . not_to include ( " --user= #{ machine . ssh_info [ :username ] } " )
expect ( args ) . to include ( " --extra-vars=ansible_ssh_user=' #{ machine . ssh_info [ :username ] } ' " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-11-02 08:03:15 +00:00
end
describe " with force_remote_user option disabled " do
before do
config . force_remote_user = false
end
it " uses a --user argument to set a default remote user " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-11-02 08:03:15 +00:00
expect ( args ) . not_to include ( " --extra-vars=ansible_ssh_user=' #{ machine . ssh_info [ :username ] } ' " )
expect ( args ) . to include ( " --user= #{ machine . ssh_info [ :username ] } " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-11-02 08:03:15 +00:00
end
end
2014-03-29 08:19:26 +00:00
end
2016-09-20 20:58:41 +00:00
context " with config_file option defined " do
before do
config . config_file = existing_file
end
it " sets ANSIBLE_CONFIG environment variable " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2016-09-20 20:58:41 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] ) . to include ( " ANSIBLE_CONFIG " )
expect ( cmd_opts [ :env ] [ 'ANSIBLE_CONFIG' ] ) . to eql ( existing_file )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2016-09-20 20:58:41 +00:00
end
end
2014-04-14 08:29:10 +00:00
describe " with ask_vault_pass option " do
before do
config . ask_vault_pass = true
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables 6
2014-04-14 08:29:10 +00:00
it " should ask the vault password " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-04-14 08:29:10 +00:00
expect ( args ) . to include ( " --ask-vault-pass " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-04-14 08:29:10 +00:00
end
end
describe " with vault_password_file option " do
before do
config . vault_password_file = existing_file
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables 6
2014-04-14 08:29:10 +00:00
it " uses the given vault password file " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-04-14 08:29:10 +00:00
expect ( args ) . to include ( " --vault-password-file= #{ existing_file } " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-04-14 08:29:10 +00:00
end
end
2014-03-29 08:19:26 +00:00
describe " with raw_ssh_args " do
before do
2014-05-04 19:25:43 +00:00
config . raw_ssh_args = [ '-o ControlMaster=no' , '-o ForwardAgent=no' ]
2014-03-22 16:18:00 +00:00
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
it_should_explicitly_enable_ansible_ssh_control_persist_defaults
2014-03-22 16:18:00 +00:00
2014-03-29 08:19:26 +00:00
it " passes custom SSH options via ANSIBLE_SSH_ARGS with the highest priority " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-29 08:19:26 +00:00
cmd_opts = args . last
raw_opt_index = cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] . index ( " -o ControlMaster=no " )
default_opt_index = cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] . index ( " -o ControlMaster=auto " )
expect ( raw_opt_index ) . to be < default_opt_index
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-21 11:02:23 +00:00
end
2014-03-29 08:19:26 +00:00
2014-05-04 19:25:43 +00:00
describe " and with ssh forwarding enabled " do
before do
ssh_info [ :forward_agent ] = true
end
it " sets '-o ForwardAgent=yes' via ANSIBLE_SSH_ARGS with higher priority than raw_ssh_args values " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-05-04 19:25:43 +00:00
cmd_opts = args . last
forwardAgentYes = cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] . index ( " -o ForwardAgent=yes " )
forwardAgentNo = cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] . index ( " -o ForwardAgent=no " )
expect ( forwardAgentYes ) . to be < forwardAgentNo
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-05-04 19:25:43 +00:00
end
end
2014-03-21 11:02:23 +00:00
end
describe " with multiple SSH identities " do
before do
ssh_info [ :private_key_path ] = [ '/path/to/my/key' , '/an/other/identity' , '/yet/an/other/key' ]
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
it_should_explicitly_enable_ansible_ssh_control_persist_defaults
2014-03-21 11:02:23 +00:00
it " passes additional Identity Files via ANSIBLE_SSH_ARGS " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-21 11:02:23 +00:00
cmd_opts = args . last
2017-07-14 17:57:58 +00:00
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o IdentityFile=/an/other/identity " )
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o IdentityFile=/yet/an/other/key " )
2017-08-07 06:55:00 +00:00
} . and_return ( default_execute_result )
2014-03-21 11:02:23 +00:00
end
end
2016-10-04 13:05:45 +00:00
describe " with an identity file containing `%` " do
before do
ssh_info [ :private_key_path ] = [ '/foo%bar/key' , '/bar%%buz/key' ]
end
2017-04-06 21:57:46 +00:00
2016-10-04 13:05:45 +00:00
it " replaces `%` with `%%` " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2016-10-04 13:05:45 +00:00
cmd_opts = args . last
2017-07-14 17:57:58 +00:00
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o IdentityFile=/foo%%bar/key " )
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o IdentityFile=/bar%%%%buz/key " )
2017-08-07 06:55:00 +00:00
} . and_return ( default_execute_result )
2016-10-04 13:05:45 +00:00
end
end
2014-03-21 11:02:23 +00:00
describe " with ssh forwarding enabled " do
before do
ssh_info [ :forward_agent ] = true
end
2015-11-02 08:03:15 +00:00
it_should_set_arguments_and_environment_variables
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
it_should_explicitly_enable_ansible_ssh_control_persist_defaults
2014-03-21 11:02:23 +00:00
it " enables SSH-Forwarding via ANSIBLE_SSH_ARGS " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2014-03-21 11:02:23 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o ForwardAgent=yes " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-21 11:02:23 +00:00
end
2016-09-21 21:19:55 +00:00
end
describe " with an ssh proxy command configured " do
before do
ssh_info [ :proxy_command ] = " ssh -W %h:%p -q user@remote_libvirt_host "
end
it " sets '-o ProxyCommand' via ANSIBLE_SSH_ARGS " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2016-09-21 21:19:55 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o ProxyCommand='ssh -W %h:%p -q user@remote_libvirt_host' " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2016-09-21 21:19:55 +00:00
end
2014-03-21 11:02:23 +00:00
end
2015-02-10 14:28:00 +00:00
context " with verbose option defined " do
%w( vv vvvv ) . each do | verbose_option |
describe " with a value of ' #{ verbose_option } ' " do
before do
config . verbose = verbose_option
end
2015-11-08 13:01:23 +00:00
it_should_set_arguments_and_environment_variables 6
2015-02-10 14:28:00 +00:00
it_should_set_optional_arguments ( { " verbose " = > " - #{ verbose_option } " } )
it " shows the ansible-playbook command and set verbosity to '- #{ verbose_option } ' level " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to receive ( :detail )
. with ( " PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit= \" machine1 \" --inventory-file= #{ generated_inventory_dir } - #{ verbose_option } playbook.yml " )
2015-02-10 14:28:00 +00:00
end
end
describe " with a value of '- #{ verbose_option } ' " do
before do
config . verbose = " - #{ verbose_option } "
end
2015-11-08 13:01:23 +00:00
it_should_set_arguments_and_environment_variables 6
2015-02-10 14:28:00 +00:00
it_should_set_optional_arguments ( { " verbose " = > " - #{ verbose_option } " } )
it " shows the ansible-playbook command and set verbosity to '- #{ verbose_option } ' level " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to receive ( :detail )
. with ( " PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit= \" machine1 \" --inventory-file= #{ generated_inventory_dir } - #{ verbose_option } playbook.yml " )
2015-02-10 14:28:00 +00:00
end
end
2014-03-31 14:25:16 +00:00
end
2015-02-10 14:28:00 +00:00
describe " with an invalid string " do
before do
config . verbose = " wrong "
end
2014-03-31 14:25:16 +00:00
2015-11-08 13:01:23 +00:00
it_should_set_arguments_and_environment_variables 6
2015-02-10 14:28:00 +00:00
it_should_set_optional_arguments ( { " verbose " = > " -v " } )
it " shows the ansible-playbook command and set verbosity to '-v' level " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to receive ( :detail )
. with ( " PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_HOST_KEY_CHECKING=false ANSIBLE_SSH_ARGS='-o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --limit= \" machine1 \" --inventory-file= #{ generated_inventory_dir } -v playbook.yml " )
2015-02-10 14:28:00 +00:00
end
2015-06-01 06:36:09 +00:00
end
2015-02-10 14:28:00 +00:00
describe " with an empty string " do
before do
config . verbose = " "
end
it_should_set_arguments_and_environment_variables
it " doesn't show the ansible-playbook command " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to_not receive ( :detail ) . with ( / ansible-playbook / )
2015-02-10 14:28:00 +00:00
end
end
2015-06-01 06:36:09 +00:00
end
describe " without colorized output " do
before do
2017-04-06 21:57:46 +00:00
allow ( machine . env ) . to receive ( :ui ) . and_return ( Vagrant :: UI :: Basic . new )
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
allow ( machine . env . ui ) . to receive ( :warn ) . and_return ( " " ) # hide the breaking change warning
2015-06-01 06:36:09 +00:00
end
it " disables ansible-playbook colored output " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-06-01 06:36:09 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] ) . to_not include ( " ANSIBLE_FORCE_COLOR " )
expect ( cmd_opts [ :env ] [ 'ANSIBLE_NOCOLOR' ] ) . to eql ( " true " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-03-31 14:25:16 +00:00
end
end
2017-08-29 03:32:38 +00:00
context " with version option set " do
before do
config . version = " 2.3.4.5 "
end
describe " and the installed ansible version is correct " do
before do
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " ansible #{ config . version } \n ... \n " )
end
it " executes ansible-playbook command " do
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) . and_return ( default_execute_result )
end
end
describe " and there is an ansible version mismatch " do
before do
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " ansible 1.9.6 \n ... \n " )
end
2017-09-01 06:05:50 +00:00
it " raises an error about the ansible version mismatch " , skip_before : false , skip_after : true do
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
2017-08-29 03:32:38 +00:00
expect { subject . provision } . to raise_error ( VagrantPlugins :: Ansible :: Errors :: AnsibleVersionMismatch )
end
end
describe " and the installed ansible version cannot be detected " do
before do
2017-09-01 06:05:50 +00:00
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " " )
2017-08-29 03:32:38 +00:00
end
2017-09-01 06:05:50 +00:00
it " skips the ansible version check and executes ansible-playbook command " do
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) . and_return ( default_execute_result )
end
end
describe " with special value: 'latest' " do
before do
config . version = :latest
allow ( subject ) . to receive ( :gather_ansible_version ) . and_return ( " ansible 2.2.0.1 \n ... \n " )
end
it " skips the ansible version check and executes ansible-playbook command " do
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) . and_return ( default_execute_result )
2017-08-29 03:32:38 +00:00
end
end
end
2015-11-17 21:06:06 +00:00
describe " with galaxy support " do
before do
config . galaxy_role_file = existing_file
end
it " raises an error when ansible-galaxy command fails " , skip_before : true , skip_after : true do
config . finalize!
2017-11-10 19:40:13 +00:00
ensure_that_config_is_valid
2016-09-20 20:58:41 +00:00
2017-04-06 21:57:46 +00:00
allow ( subject ) . to receive ( :check_path )
allow ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. and_return ( Vagrant :: Util :: Subprocess :: Result . new ( 1 , " " , " " ) )
2015-11-17 21:06:06 +00:00
expect { subject . provision } . to raise_error ( VagrantPlugins :: Ansible :: Errors :: AnsibleCommandFailed )
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
it " execute three commands: ansible --version, ansible-galaxy, and ansible-playbook " do
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. once
. with ( 'ansible' , '--version' , { :notify = > [ :stdout , :stderr ] } )
. and_return ( default_execute_result )
2017-08-14 16:54:33 +00:00
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. once
. with ( 'ansible-galaxy' , any_args )
. and_return ( default_execute_result )
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute )
. once
. with ( 'ansible-playbook' , any_args )
. and_return ( default_execute_result )
end
2017-08-07 06:55:00 +00:00
2017-08-14 16:54:33 +00:00
it " doesn't show the ansible-galaxy command " do
expect ( machine . env . ui ) . to_not receive ( :detail ) . with ( / ansible-galaxy / )
2015-11-17 21:06:06 +00:00
end
describe " with verbose option enabled " do
before do
2017-08-14 16:54:33 +00:00
config . galaxy_roles_path = " /tmp/roles "
2015-11-17 21:06:06 +00:00
config . verbose = true
end
2017-08-14 16:54:33 +00:00
it " shows the ansible-galaxy command in use " do
expect ( machine . env . ui ) . to receive ( :detail )
. with ( %Q( ansible-galaxy install --role-file=' #{ existing_file } ' --roles-path='/tmp/roles' --force ) )
end
2015-11-17 21:06:06 +00:00
end
end
2016-06-11 05:28:05 +00:00
context " with galaxy_roles_path option defined " do
before do
config . galaxy_roles_path = " my-roles "
end
it " sets ANSIBLE_ROLES_PATH with corresponding absolute path " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2016-06-11 05:28:05 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] ) . to include ( " ANSIBLE_ROLES_PATH " )
expect ( cmd_opts [ :env ] [ 'ANSIBLE_ROLES_PATH' ] ) . to eql ( File . join ( machine . env . root_path , " my-roles " ) )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2016-06-11 05:28:05 +00:00
end
end
2016-03-05 15:59:38 +00:00
context " with extra_vars option defined " do
describe " with a hash value " do
before do
2017-09-06 14:25:05 +00:00
config . extra_vars = { var1 : %Q( string with 'apo$trophe$', \\ , " and = ) , var2 : { x : 42 } }
2016-03-05 15:59:38 +00:00
end
2017-09-06 14:25:05 +00:00
it_should_set_optional_arguments ( { " extra_vars " = > " --extra-vars={ \" var1 \" : \" string with 'apo$trophe$', \\ \\ , \\ \" and = \" , \" var2 \" :{ \" x \" :42}} " } )
2016-03-05 15:59:38 +00:00
end
describe " with a string value referring to file path (with the '@' prefix) " do
before do
config . extra_vars = " @ #{ existing_file } "
end
it_should_set_optional_arguments ( { " extra_vars " = > " --extra-vars=@ #{ File . expand_path ( __FILE__ ) } " } )
end
end
2015-02-10 14:28:00 +00:00
# The Vagrant Ansible provisioner does not validate the coherency of
2017-08-14 16:54:33 +00:00
# argument combinations, and lets ansible-playbook complain.
2014-03-29 08:19:26 +00:00
describe " with a maximum of options " do
before do
2014-03-31 14:25:16 +00:00
# vagrant general options
ssh_info [ :forward_agent ] = true
ssh_info [ :private_key_path ] = [ '/my/key1' , '/my/key2' ]
2014-03-29 08:19:26 +00:00
# command line arguments
2016-06-11 05:28:05 +00:00
config . galaxy_roles_path = " /up/to the stars "
2017-09-06 14:25:05 +00:00
config . extra_vars = { var1 : %Q( string with 'apo$trophe$', \\ , " and = ) , var2 : { x : 42 } }
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
config . become = true
config . become_user = 'deployer'
2014-03-29 08:19:26 +00:00
config . verbose = " vvv "
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
config . ask_become_pass = true
2014-04-25 19:59:39 +00:00
config . ask_vault_pass = true
config . vault_password_file = existing_file
2014-03-29 08:19:26 +00:00
config . tags = %w( db www )
config . skip_tags = %w( foo bar )
config . limit = 'machine*:&vagrant:!that_one'
2016-03-05 16:15:28 +00:00
config . start_at_task = " joe's awesome task "
2016-04-20 16:05:28 +00:00
config . raw_arguments = [ " --why-not " , " --su-user=foot " , " --ask-su-pass " , " --limit=all " , " --private-key=./myself.key " , " --extra-vars='{ \" var3 \" : \" foo \" }' " ]
2014-03-29 08:19:26 +00:00
# environment variables
2016-09-20 20:58:41 +00:00
config . config_file = existing_file
2014-03-29 08:19:26 +00:00
config . host_key_checking = true
config . raw_ssh_args = [ '-o ControlMaster=no' ]
end
2016-09-20 20:58:41 +00:00
it_should_set_arguments_and_environment_variables 21 , 6 , true
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
it_should_explicitly_enable_ansible_ssh_control_persist_defaults
2017-09-06 14:25:05 +00:00
it_should_set_optional_arguments ( { " extra_vars " = > " --extra-vars={ \" var1 \" : \" string with 'apo$trophe$', \\ \\ , \\ \" and = \" , \" var2 \" :{ \" x \" :42}} " ,
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 " = > " --sudo " ,
" become_user " = > " --sudo-user=deployer " ,
2014-04-25 19:59:39 +00:00
" verbose " = > " -vvv " ,
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_become_pass " = > " --ask-sudo-pass " ,
2014-04-25 19:59:39 +00:00
" ask_vault_pass " = > " --ask-vault-pass " ,
" vault_password_file " = > " --vault-password-file= #{ File . expand_path ( __FILE__ ) } " ,
" tags " = > " --tags=db,www " ,
" skip_tags " = > " --skip-tags=foo,bar " ,
" limit " = > " --limit=machine*:&vagrant:!that_one " ,
2016-03-05 16:15:28 +00:00
" start_at_task " = > " --start-at-task=joe's awesome task " ,
2014-03-29 08:19:26 +00:00
} )
provisioners/ansible: force --connection=ssh
When `--connection` argument is not specified, Ansible will use the
'smart' mode, which can either use `ssh` or `paramiko` transports,
depending of the version of OpenSSH available. If OpenSSH version is new
enough to support ControlPersist technology, `ssh` will be used.
See also http://docs.ansible.com/intro_configuration.html#transport.
In order to support some advanced features of Vagrant (e.g. multiple ssh
private key identities or ssh forwarding), the Ansible provisioner
already must force `ssh` connection mode.
Having to deal with the possible fallback to `paramiko` increase the
burden of special cases that Ansible provisioner must handle, without
any added value, as Vagrant is based on OpenSSH and its users are
usually using modern operating systems.
With this change, the Ansible provisioner will officially only support
`ssh`. It will still be possible to switch to another connection mode
via `raw_arguments`, but it will breach the "contract", and no
(community) support can be expected in such use case.
ref #3900, #3396
2014-11-29 22:29:46 +00:00
2014-04-25 19:59:39 +00:00
it " also includes given raw arguments " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-05-29 08:18:21 +00:00
expect ( args ) . to include ( " --why-not " )
2014-04-25 19:59:39 +00:00
expect ( args ) . to include ( " --su-user=foot " )
expect ( args ) . to include ( " --ask-su-pass " )
2015-05-29 08:18:21 +00:00
expect ( args ) . to include ( " --limit=all " )
expect ( args ) . to include ( " --private-key=./myself.key " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2014-04-25 19:59:39 +00:00
end
2014-03-31 14:25:16 +00:00
it " shows the ansible-playbook command, with additional quotes when required " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to receive ( :detail )
2017-09-06 14:25:05 +00:00
. with ( %Q( PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ANSIBLE_ROLES_PATH='/up/to the stars' ANSIBLE_CONFIG=' #{ existing_file } ' ANSIBLE_HOST_KEY_CHECKING=true ANSIBLE_SSH_ARGS='-o IdentitiesOnly=yes -o IdentityFile=/my/key1 -o IdentityFile=/my/key2 -o ForwardAgent=yes -o ControlMaster=no -o ControlMaster=auto -o ControlPersist=60s' ansible-playbook --connection=ssh --timeout=30 --ask-sudo-pass --ask-vault-pass --limit="machine*:&vagrant:!that_one" --inventory-file= #{ generated_inventory_dir } --extra-vars= \\ { \\ "var1 \\ ": \\ "string \\ with \\ \\ 'apo \\ $trophe \\ $ \\ ', \\ \\ \\ \\ \\ , \\ \\ \\ \\ " \\ and \\ \\ = \\ ", \\ "var2 \\ ": \\ { \\ "x \\ ":42 \\ } \\ } --sudo --sudo-user=deployer -vvv --vault-password-file= #{ existing_file } --tags=db,www --skip-tags=foo,bar --start-at-task="joe's awesome task" --why-not --su-user=foot --ask-su-pass --limit=all --private-key=./myself.key --extra-vars='{ \" var3 \" : \" foo \" }' playbook.yml ) )
2014-03-31 14:25:16 +00:00
end
2014-03-29 08:19:26 +00:00
end
2015-01-12 08:37:16 +00:00
#
# Special cases related to the VM provider context
#
context " with Docker provider on a non-Linux host " do
2015-05-29 08:36:17 +00:00
2015-01-12 08:37:16 +00:00
let ( :fake_host_ssh_info ) { {
private_key_path : [ '/path/to/docker/host/key' ] ,
username : 'boot9docker' ,
host : '127.0.0.1' ,
port : 2299
} }
let ( :fake_host_vm ) {
double ( " host_vm " ) . tap do | h |
2017-04-06 21:57:46 +00:00
allow ( h ) . to receive ( :ssh_info ) . and_return ( fake_host_ssh_info )
2015-05-29 08:36:17 +00:00
end
2015-01-12 08:37:16 +00:00
}
before do
2017-04-06 21:57:46 +00:00
allow ( machine ) . to receive ( :provider_name ) . and_return ( :docker )
allow ( machine . provider ) . to receive ( :host_vm? ) . and_return ( true )
allow ( machine . provider ) . to receive ( :host_vm ) . and_return ( fake_host_vm )
2015-01-12 08:37:16 +00:00
end
it " uses an SSH ProxyCommand to reach the VM " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-01-12 08:37:16 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to include ( " -o ProxyCommand='ssh boot9docker@127.0.0.1 -p 2299 -i /path/to/docker/host/key -o Compression=yes -o ConnectTimeout=5 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no exec nc %h %p 2>/dev/null' " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-01-12 08:37:16 +00:00
end
end
2015-01-12 07:58:29 +00:00
#
# Special cases related to the Vagrant Host operating system in use
#
2015-11-17 07:00:24 +00:00
context " on a Windows host " do
before do
2017-04-06 21:57:46 +00:00
allow ( Vagrant :: Util :: Platform ) . to receive ( :windows? ) . and_return ( true )
allow ( machine . ui ) . to receive ( :warn )
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
# Set the compatibility mode to only get the Windows warning
2017-09-01 06:05:50 +00:00
config . compatibility_mode = VagrantPlugins :: Ansible :: COMPATIBILITY_MODE_V1_8
2015-11-17 07:00:24 +00:00
end
it " warns that Windows is not officially supported for the Ansible control machine " do
2017-08-14 16:54:33 +00:00
expect ( machine . env . ui ) . to receive ( :warn )
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
. with ( I18n . t ( " vagrant.provisioners.ansible.windows_not_supported_for_control_machine " ) + " \n " )
2015-11-17 07:00:24 +00:00
end
end
context " on a Solaris-like host " do
2015-01-12 07:58:29 +00:00
before do
2017-04-06 21:57:46 +00:00
allow ( Vagrant :: Util :: Platform ) . to receive ( :solaris? ) . and_return ( true )
2015-01-12 07:58:29 +00:00
end
it " does not set IdentitiesOnly=yes in ANSIBLE_SSH_ARGS " 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
expect ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-01-12 07:58:29 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to_not include ( " -o IdentitiesOnly=yes " )
2017-04-06 21:57:46 +00:00
} . and_return ( default_execute_result )
2015-01-12 07:58:29 +00:00
end
describe " and with host_key_checking option enabled " do
it " does not set ANSIBLE_SSH_ARGS environment variable " do
config . host_key_checking = true
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 ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2015-01-12 07:58:29 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] ) . to_not include ( 'ANSIBLE_SSH_ARGS' )
2017-04-06 21:57:46 +00:00
} . and_return ( Vagrant :: Util :: Subprocess :: Result . new ( 0 , " " , " " ) )
2015-01-12 07:58:29 +00:00
end
end
end
2017-04-11 11:40:14 +00:00
describe 'with config.ssh.keys_only = false' do
it 'does not set IdentitiesOnly=yes in ANSIBLE_SSH_ARGS' do
ssh_info [ :keys_only ] = false
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 ( Vagrant :: Util :: Subprocess ) . to receive ( :execute ) . with ( 'ansible-playbook' , any_args ) { | * args |
2017-04-11 11:40:14 +00:00
cmd_opts = args . last
expect ( cmd_opts [ :env ] [ 'ANSIBLE_SSH_ARGS' ] ) . to_not include ( " -o IdentitiesOnly=yes " )
2017-08-07 06:55:00 +00:00
} . and_return ( default_execute_result )
2017-04-11 11:40:14 +00:00
end
end
2014-03-21 11:02:23 +00:00
end
end