Switch to recommended Ansible 2.x arguments with backwards compatible aliases #6570

gildegoma · 2015-11-20T19:28:42Z

ask_become_pass (aliased as ask_sudo_pass)
become (aliased as sudo)
become_user (aliased as sudo_user)
some parameters in the generated inventory (ansible_user, ansible_host and ansible_port)

Deprecation warnings should also be activated for all these aliases.

Notes:

The "become" parameters were completely introduced in Ansible 1.9
The "not ssh specific" parameters (e.g. ansible_user) were introduced in Ansible 2.0
The legacy parameters (e.g. ansible_ssh_user) will probably be removed in Ansible 2.2+.

Open Questions:

Introduce a "strict" mode, where deprecated parameters are rejected. In such mode, all the settings behind the scene are following Ansible 2+ recommendations (e.g. inventory settings like ansible_host instead of ansible_ssh_host)
The "strict" mode could be implemented with a "compatibility_level" option, which for now would support two values: ansible-1.8 and ansible-2.0

Possible Roadmap:

Vagrant 1.8.x: backwards compatible introduction of new behaviors (with deprecation warnings)
Vagrant 1.9.0: breaking change 1: switch the compatibility_level default value to "ansible-2.0" to encourage users to upgrade.
Vagrant 2.0.0 (or 1.10.0): breaking change 2: fully remove support of "ansible-1.8" compatibility level

Note: Depending on the situation (ansible 1.9 and 2.x adoption and evolution by the time of releasing Vagrant 1.9), we also could consider introducing the two breaking changes at the same time (i.e. directly in Vagrant 1.9.0)

The text was updated successfully, but these errors were encountered:

This is an attempt to solve #7665. Revert the change applied by f56a6e0 (#12310), as the inventory generated by Vagrant still rely on the legacy `_ssh` setting names for backwards compatibility reasons. See also hashicorp/vagrant#6570

gildegoma · 2016-01-26T06:07:32Z

Issue description updated after #6927 report.

Changes: - Add "config" unit tests for `ansible_local` (guest) - Share some "config" examples between both ansible provisioners - Move `config_host.rb` specific examples to `config/host.rb` - Add a requirement to "../helpers" in `config/guest.rb` in order to be able to run the related unit tests References: - This is the first part of GH-6633 resolution - This change is a handy prerequisite for GH-6570 Not addressed yet: - FIXME (guest.rb): Some test-double stubs are currently not working as expected, and the related checks are commented out for the moment (no idea why, but this is not urgent to be fixed because of GH-7335 rejection. See also GH-6984) - FIXME (shared.rb): The guest-based config should actually NOT return an error when the extra_vars file cannot be found, but only display a a warning (similarly to the changes done for GH-6764, see 4e451c6)

Changes: - Add "config" unit tests for `ansible_local` (guest) - Share some "config" examples between both ansible provisioners - Move `config_host.rb` specific examples to `config/host.rb` - Add a requirement to "../helpers" in `config/guest.rb` in order to be able to run the related unit tests References: - This is the first part of GH-6633 resolution - This change is a handy prerequisite for GH-6570 Not addressed yet: - FIXME (guest.rb): Some test-double stubs are currently not working as expected, and the related checks are commented out for the moment (no idea why, but this is not urgent to be fixed because of GH-7335 rejection. See also GH-6984) - FIXME (shared.rb): The guest-based config should actually NOT return an error when the extra_vars file cannot be found, but only display a a warning (similarly to the changes done for GH-6763, see 4e451c6)

gildegoma · 2016-11-13T16:31:01Z

I confirm that I'll provide a fix for this within the next weeks. The roadmap will be following:

Vagrant 1.9.0 will introduce
- A new compatibility_mode option, set by default to "Version 1.x" for backward compatibility. A warning will encourage to explicitly set this option in Vagrantfile in case compatibility with Ansible .1x is required.
- New options sudo, sudo_user and ask_become_pass (with backwards compatible aliases for now deprecated sudo, sudo_user and ask_sudo_pass options).
Vagrant 1.10.0 (or 2.0.0) will then introduce some breaking changes
- Switch the compatibility_mode default to "Version 2.x"
- Removal of the three deprecated options/aliases.

Questions to @chrisroberts:

Can I assign you to review this upcoming feature pull request?
Do you already have an ETA for Vagrant 1.9.0?

chrisroberts · 2016-11-14T21:29:28Z

@gildegoma Hi! Yes, feel free to assign me when it's ready for review. The 1.9.0 release will be happening shortly, so I'm going to move this into the 1.9 bucket and will pull it into the 1.9.1 milestone once it's created.

schlueter · 2017-07-26T21:02:56Z

I'm still seeing Ansible's sudo deprecation error with Vagrant 1.9.1:

$ vagrant --version
Vagrant 1.9.1
$ vagrant provision
==> default: Running provisioner: ansible...
    default: Running ansible-playbook...
[DEPRECATION WARNING]: The sudo command line option has been deprecated in
favor of the "become" command line arguments.
This feature will be removed in
version 2.6. Deprecation warnings can be disabled by setting
deprecation_warnings=False in ansible.cfg.

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.

Before this change, only the ansible_local provisioner supported this option (for ansible version requirement, and pip installation). Now, the ansible host-based provisioner can also require a exact ansible version. Resolve #8914 Note: this has been added as part of #6570 resolution, since the introduction of the `compatibility_mode` auto-detection made both provisioners made capable to detect ansible version. Pending: optimize the code to avoid duplicated executions of "ansible --version" command.

gildegoma · 2017-09-02T09:20:07Z

The PR #8913 will hopefully soon be merged to resolve the changes requested here.

@vagrant-ansible-community: If you're interested in these additions, please have a look at the upcoming documentation. Feedbacks are still welcome, but any "major change" proposal needs to be reported within the next days since the next release is around the corner.

Thank you for sharing your thoughts in this thread of the Vagrant mailing list instead of this GitHub issue.

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.

Before this change, only the ansible_local provisioner supported this option (for ansible version requirement, and pip installation). Now, the ansible host-based provisioner can also require a exact ansible version. Resolve #8914 Note: this has been added as part of #6570 resolution, since the introduction of the `compatibility_mode` auto-detection made both provisioners made capable to detect ansible version. Pending: optimize the code to avoid duplicated executions of "ansible --version" command.

With this change, it is now possible to get rid of many deprecation messages successively introduced in Ansible 1.9, and 2.0. More interesting, the generated inventory will contain the recommended variable names (e.g. `ansible_host` instead of `ansible_ssh_host`) when the compatibility mode is set to '2.0'. Details: - Add `compatibility_mode` option to control the Ansible parameters format to be used. The value corresponds to the minimal version supported. For the moment, possible values are '1.8' (corresponding to Vagrant's former behaviour) or '2.0'. Note that a dynamic inventory generated in compatibility mode '2.0' is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far supports inventory format generated by the compatibility mode '1.8'. - Add compatibility mode auto-detection, based on the available Ansible version. This is the default behaviour in order to bring a maximum of user friendliness. The drawback of this approach is to let potential compatibility breaking risks, for `ansible` provisioner setups that already integrate Ansible 2.x **AND** rely on the existence of the generated `_ssh` variable names. Thanks to the vagrant warnings (and its release notes), I argue that it is worth to offer auto-detection by default, which offers a sweet transition to most users. - Add `become`, `become_user` and `ask_become_pass` options and their backwards compatible aliases. The legacy options are now deprecated. Note that we intentionally didn't provide a '1.9' compatibility mode, as it would add extra-complexity for practically no added-value. To my knowledge, the Ansible 2.x series haven't introduced yet any major changes or deprecations that would motivate to introduce a higher version compatibility mode (to be confirmed/verified). Resolve hashicorpGH-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.

Before this change, only the ansible_local provisioner supported this option (for ansible version requirement, and pip installation). Now, the ansible host-based provisioner can also require a exact ansible version. Resolve hashicorp#8914 Note: this has been added as part of hashicorp#6570 resolution, since the introduction of the `compatibility_mode` auto-detection made both provisioners made capable to detect ansible version. Pending: optimize the code to avoid duplicated executions of "ansible --version" command.

ghost · 2020-03-31T02:31:44Z

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

gildegoma added enhancement thinking provisioner/ansible labels Nov 20, 2015

gildegoma self-assigned this Nov 20, 2015

gildegoma mentioned this issue Dec 16, 2015

Ansible dynamic inventory missing the variable 'ansible_user' #6672

Closed

gildegoma mentioned this issue Jan 26, 2016

ansible_ssh_user is deprecated in Ansible 2 #6927

Closed

gildegoma mentioned this issue Feb 23, 2016

Generated inventory for Ansible always uses ansible_ssh_* vars #7067

Closed

gildegoma added this to the 1.8.2 milestone May 26, 2016

gildegoma mentioned this issue May 28, 2016

Add test coverage for ansible_local provisioner #6633

Open

4 tasks

gildegoma added the provisioner/ansible_local label Jun 7, 2016

sethvargo modified the milestones: 1.8.2, 1.8.4, 1.8.5 Jun 10, 2016

gildegoma mentioned this issue Jul 7, 2016

Allow to override the "host" and "port" values in the generated inventory #7552

Open

sethvargo modified the milestones: 1.8.5, 1.8.6 Jul 19, 2016

chrisroberts added this to the 1.8.7 milestone Sep 28, 2016

chrisroberts removed this from the 1.8.6 milestone Sep 28, 2016

ravbaba mentioned this issue Sep 30, 2016

Ansible failed because of undefined ansible_port Capgemini/Apollo#714

Open

chrisroberts modified the milestones: 1.9, 1.8.7 Oct 26, 2016

gildegoma removed the thinking label Nov 13, 2016

gildegoma modified the milestones: 1.9.0, Secondary Nov 13, 2016

chrisroberts modified the milestones: 1.9, 1.9.0 Nov 14, 2016

ghost mentioned this issue Dec 20, 2016

Allow ansible host and port to be overridden #8131

Closed

chrisroberts modified the milestones: 1.9.5, 2.0 May 16, 2017

gildegoma mentioned this issue Aug 24, 2017

Ansible: Add "compatibility_mode" and "*become*" common options; Move "version" to common options #8913

Merged

13 tasks

gildegoma added the has-pr label Aug 24, 2017

chrisroberts closed this as completed in #8913 Sep 6, 2017

ghost locked and limited conversation to collaborators Mar 31, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Switch to recommended Ansible 2.x arguments with backwards compatible aliases #6570

Switch to recommended Ansible 2.x arguments with backwards compatible aliases #6570

gildegoma commented Nov 20, 2015

gildegoma commented Jan 26, 2016

gildegoma commented Nov 13, 2016 •

edited

chrisroberts commented Nov 14, 2016

schlueter commented Jul 26, 2017 •

edited

gildegoma commented Sep 2, 2017

ghost commented Mar 31, 2020

Switch to recommended Ansible 2.x arguments with backwards compatible aliases #6570

Switch to recommended Ansible 2.x arguments with backwards compatible aliases #6570

Comments

gildegoma commented Nov 20, 2015

gildegoma commented Jan 26, 2016

gildegoma commented Nov 13, 2016 • edited

chrisroberts commented Nov 14, 2016

schlueter commented Jul 26, 2017 • edited

gildegoma commented Sep 2, 2017

ghost commented Mar 31, 2020

gildegoma commented Nov 13, 2016 •

edited

schlueter commented Jul 26, 2017 •

edited