# Ansible 2.0 upgrade questions **URL:** \ **Category:** Ansible Project\ **Tags:** windows\ **Created:** [January 12, 2016, 10:16pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187 "2016-01-12T22:16:57Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Jacob\_Weber1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Jacob\_Weber1](https://forum.ansible.com/u/Jacob_Weber1)\ **Post date:** [January 12, 2016, 10:16pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/1 "2016-01-12T22:16:57Z")
I’m trying my playbooks with Ansible 2.0, and ran into a few minor issues: - The Ansible upgrade guide says “Using variables for task parameters is unsafe and will be removed in a future version.” What does this mean exactly? I use variables in task parameters all the time – this seems fundamental to Ansible. Can you clarify this? Is it only when you define variables and use them in the same task, like in the example? - When my source and destination boxes are Linux, and I deployed a template with Windows line endings, they used to be converted to Unix line endings (in Ansible 1.9). Now the Windows line endings are preserved, but I didn’t see this in the changelog. - The upgrade guide says I should receive a deprecation warning in this case: “Bare variables in with\_ loops should instead use the “{{var}}” syntax, which helps eliminate ambiguity.” But I’m not getting that warning for things like “with\_items: some\_variable”. Thanks, Jacob ---
**Author:** ![James\_Cammarata](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@James\_Cammarata](https://forum.ansible.com/u/James_Cammarata)\ **Post date:** [January 13, 2016, 1:02pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/2 "2016-01-13T13:02:44Z")
The first message is for this: - some\_module: args: “{{some\_var}}” This is, in our opinion, very unsafe - especially when that variable may come from something like a fact. It has not been disabled, but will be removed after 2 major versions. I was unaware of any feature where we silently converted Windows line endings to POSIX-compliant versions, but you can open an issue in Github for this. Finally, this may be an oversight, or a bug in which the deprecation message for bare variables in loops is not being triggered correctly. This is fairly minor, but we can look into that as well. ---
**Author:** ![Tim1](https://avatars.discourse-cdn.com/v4/letter/t/b782af/32.png) [@Tim1](https://forum.ansible.com/u/Tim1)\ **Post date:** [January 13, 2016, 4:23pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/3 "2016-01-13T16:23:33Z")
Is this specifically related to the args parameter? Or all variable content to tasks? -tim ---
**Author:** ![James\_Cammarata](https://avatars.discourse-cdn.com/v4/letter/j/7c8e57/32.png) [@James\_Cammarata](https://forum.ansible.com/u/James_Cammarata)\ **Post date:** [January 13, 2016, 4:25pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/4 "2016-01-13T16:25:01Z")
It should be specifically related to args. ---
**Author:** ![Toshio\_Kuratomi](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Toshio\_Kuratomi](https://forum.ansible.com/u/Toshio_Kuratomi)\ **Post date:** [January 13, 2016, 4:41pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/5 "2016-01-13T16:41:49Z")
it's this type of construct that's being deprecated: ---
**Author:** ![Jacob\_Weber1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Jacob\_Weber1](https://forum.ansible.com/u/Jacob_Weber1)\ **Post date:** [January 13, 2016, 6:50pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/6 "2016-01-13T18:50:38Z")
Thanks for all the replies. The deprecation of “using variables for task parameters” makes sense now. But the example in the [porting guide](https://github.com/ansible/ansible/blob/devel/docsite/rst/porting_guide_2.0.rst) doesn’t use “args”, it uses: - debug: “{{debug\_params}}” Maybe that could be clarified. Jacob ---
**Author:** ![Toshio\_Kuratomi](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Toshio\_Kuratomi](https://forum.ansible.com/u/Toshio_Kuratomi)\ **Post date:** [January 13, 2016, 7:14pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/7 "2016-01-13T19:14:52Z")
The syntax in the porting guide is also deprecated for the same reason. How does this look as an updated example?       tasks:         # These are both deprecated:         - debug: "{{debug\_params}}"         - debug:           args: "{{debug\_params}}"         # Use this instead:         - debug:             msg: "{{debug\_params['msg']}}" -Toshio ---
**Author:** ![Jacob\_Weber1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Jacob\_Weber1](https://forum.ansible.com/u/Jacob_Weber1)\ **Post date:** [January 13, 2016, 7:54pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/8 "2016-01-13T19:54:50Z")
Sure. Maybe the description should read “using a dictionary variable to supply all task parameters…” ---
**Author:** ![Toshio\_Kuratomi](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Toshio\_Kuratomi](https://forum.ansible.com/u/Toshio_Kuratomi)\ **Post date:** [January 13, 2016, 9:15pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/9 "2016-01-13T21:15:38Z")
Done! Thanks! -Toshio ---
**Author:** ![Adam\_Brown](https://avatars.discourse-cdn.com/v4/letter/a/bc79bd/32.png) [@Adam\_Brown](https://forum.ansible.com/u/Adam_Brown)\ **Post date:** [January 27, 2016, 11:16pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/10 "2016-01-27T23:16:40Z")
We currently use this pattern a lot to pass asymmetrical data into a module, like so: - hosts: localhost vars: percona\_dbs\_to\_create: - name: test1 encoding: utf8 collation: utf8\_general\_ci login\_host: 192.168.222.2 - name: test2 encoding: utf8 collation: utf8\_general\_ci tasks: - name: Create databases action: mysql\_db args: “{{ item }}” with\_items: percona\_dbs\_to\_create To make this work in the future, we’d have to redefine the default value of login\_host for the test2 item in percona\_dbs\_to\_create. That’s not bad for a small example like this, but gets out of hand quickly when dealing with larger data sets that contain a lot more options. Is there another way to address this situation that I’m missing? ---
**Author:** ![cohen.ben](https://avatars.discourse-cdn.com/v4/letter/c/c89c15/32.png) [@cohen.ben](https://forum.ansible.com/u/cohen.ben)\ **Post date:** [February 18, 2016, 1:10am UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/11 "2016-02-18T01:10:52Z")
I echo Adam Brown. I use this pattern a lot. I’d really like a good alternative if this is going away … Here’s another real-world example that is generating these deprecation warnings from my current in-use code: (inside a var file) some\_project: git: repo: “git://…” dest: “{{ some\_magic\_path }}” force: yes version: “5.1” recursive: no some\_project2: git: repo: “git://…” dest: “{{ some\_magic\_path }}” force: yes version: “5.1” recursive: no … (inside some playbook) tasks: - name: “Ensure correct version of some source code fetched into a magic place via git” action: git args: “{{ some\_project.git }}” tags: - fetch\_some\_project Thanks to this deprecation I’ll have to use this much more verbose pattern (or is there a better way)? tasks: - name: “Ensure correct version of some source code fetched into magic place via git” git: repo: “{{ some\_project.git.repo }}” dest: “{{ some\_project.git.dest }}” force: “{{ some\_project.git.force }}” version: “{{ some\_project.git.version }}” recursive: “{{ some\_project.git.recursive }}” This second approach is worse for a few reasons: - its more verbose and repetitive - suppose I have many such git repositories and want to centralize the declaration of their parameters for ease of auditing (as in some\_project1, some\_project2, …). Suppose I hit an edge case when I add a some\_projectN repository and discover that I actually need to pass in a value of the accept\_hotkey parameter as an argument when checking out that repository. I hadn’t been specifying this value for all the other repo’s. For example suppose I discover I need to allow invalid hostkeys with the accept\_hotkey parameter. I need to either – (1) go back and specify a value for this parameter for all the similar uses of the git module, then also go to all occurrences of the tasks and add this new parameter (2) override the task call site associated with some\_projectN and add in the additional accept\_hotkey parameter (losing the auditing ease of declaring all these magic git properties together in one place and requiring special case knowledge at each task call site) I think this is a pretty unhelpful change – especially without introduction of a good alternative … ---
**Author:** ![James\_Lott](https://avatars.discourse-cdn.com/v4/letter/j/7bcc69/32.png) [@James\_Lott](https://forum.ansible.com/u/James_Lott)\ **Post date:** [June 25, 2016, 7:17pm UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/12 "2016-06-25T19:17:01Z")
Yeah this is pretty concerning. I’m not sure I understand the safety concern in cases where facts are not being used, since variable data is being provided by the administrator, and is pretty trustworthy. This is a feature with valid use cases that’s being blown away for some very elusive reasons… Is anyone on the core development team able to recommend a pattern which would solve the problems presented by the previously mentioned use cases? ---
**Author:** ![Denis\_Bozhok](https://avatars.discourse-cdn.com/v4/letter/d/3ec8ea/32.png) [@Denis\_Bozhok](https://forum.ansible.com/u/Denis_Bozhok)\ **Post date:** [December 27, 2017, 10:14am UTC](https://forum.ansible.com/t/ansible-2-0-upgrade-questions/20187/13 "2017-12-27T10:14:57Z")
Removing the function because usage of it is dangerous is like stop using cars because they are dangerous. It’s much better to write documentation about the dangerous ways of using it and keep the tool because it useful for many other reasons. User should take a decision what tools to use.