Ansible 2.0 upgrade questions

[Jacob Weber]

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

[James Cammarata]

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.

James Cammarata

Director, Ansible Core Engineering

github: jimi-c

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d1961831-e6d5-4519-8fdf-4cf56240816c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim]

Is this specifically related to the args parameter? Or all variable content to tasks?

-tim

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAMFyvFiOVqia6MoSth1Kj4eWFo%3DepK7CW5R%2BVmj4qr2NLcficA%40mail.gmail.com.

[James Cammarata]

It should be specifically related to args.

James Cammarata

Director, Ansible Core Engineering

github: jimi-c

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAB0Zv8jWQym1-Y%2BLpcppwnak0Ue4J2wQ-3bUNQC8KgLc0aASig%40mail.gmail.com.

[Toshio Kuratomi]

On Tue, Jan 12, 2016 at 2:16 PM, Jacob Weber <weber...@gmail.com> wrote:
> 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?
>

it's this type of construct that's being deprecated:

---
- hosts: localhost
vars:
params:
data: 'message'
tasks:
- ping:
args: "{{ params }}"

This is the replacement:

tasks:
- ping:
data: "{{ params['data'] }}"

> - 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.
>

Hmm... I don't see a change where we specifically set out to do that
but it makes sense. In 1.9.x some ansible modules (lineinfile and the
argument parsing in general) would make it impossible to retain
certain characteristics of your input data. Specifying trailing
newlines, for instance, could end up without newlines in the output.
In 2.0.x we tried not to do as much magic when it prevented people
from achieving those goals. If we had realized that one of those
changes was going to change automatic Unix vs Windows newline
conversion we would have called it out in the changelog but it's
probably the way we want 2.0 to behave even though we didn't
specifically add it.

If this turns out to be a wide spread problem we might be persuaded to
add a parameter to specific modules that controls line ending
conversion.

> - 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".
>

I looked at the code and see that we are not printing the deprecation
warning here even though there's a note in the code 9as well as the
changelog) that it is deprecated. I've alerted @bcoca about hte issue
and opened a bug report:
https://github.com/ansible/ansible/issues/13852

-Toshio

[Jacob Weber]

Thanks for all the replies.

The deprecation of "using variables for task parameters" makes sense now. But the example in the porting guide doesn't use "args", it uses:

- debug: "{{debug_params}}"

Maybe that could be clarified.

Jacob

[Toshio Kuratomi]

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

> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ansible-project/a4f88a0f-e38c-40fb-a693-57da28bee0b8%40googlegroups.com.

[Jacob Weber]

Sure. Maybe the description should read "using a dictionary variable to supply all task parameters..."

[Toshio Kuratomi]

Done! Thanks!

-Toshio

> https://groups.google.com/d/msgid/ansible-project/32dd744e-2ea8-4d5e-a5bf-5ad7b2d57743%40googlegroups.com.

[Adam Brown]

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?

[breatheoften]

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 ...

[James Lott]

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?

[Denis Bozhok]

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.